Re: Using each rel as both outer and inner for JOIN_ANTI
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Richard Guo <guofenglinux@gmail.com>
Cc: "Gregory Stark (as CFM)" <stark.cfm@gmail.com>,
Alvaro Herrera <alvherre@alvh.no-ip.org>,
Ronan Dunklau <ronan.dunklau@aiven.io>,
Pg Hackers <pgsql-hackers@lists.postgresql.org>,
Emre Hasegeli <emre@hasegeli.com>
Date: 2023-04-05T21:11:11Z
Lists: pgsql-hackers
Richard Guo <guofenglinux@gmail.com> writes: > Thanks for reminding. Attached is the rebased patch, with no other > changes. I think the patch is ready for commit. Pushed after a little further fooling with the comments. I also had to rebase it over 11c2d6fdf (Parallel Hash Full Join). I think I did that correctly, but it's not clear to me whether any of the existing test cases are now doing parallelized hashed right antijoins. Might be worth a little more testing. I think that Alvaro's concern about incorrect cost estimates may be misplaced. I couldn't find any obvious errors in the costing logic for this, given that we concluded that the early-exit runtime logic cannot apply. Also, when I try simply executing Richard's original test query (in a non-JIT build), the runtimes I get line up quite well ... maybe too well? ... with the cost estimates: v15 HEAD w/patch Ratio Cost estimate 173691.19 90875.33 0.52 Actual (best of 3) 514.200 ms 268.978 ms 0.52 I think the smaller differentials you guys were seeing were all about EXPLAIN ANALYZE overhead. regards, tom lane
Commits
-
Support "Right Anti Join" plan shapes.
- 16dc2703c541 16.0 landed