Re: Re: NOT IN subquery optimization - Mailing list pgsql-hackers

From David Rowley
Subject Re: Re: NOT IN subquery optimization
Date
Msg-id CAKJS1f8b_X-WsjJcP5hw6sEj7DGwer4UPcVDFUPKiWO1RR5pvw@mail.gmail.com
Whole thread Raw
In response to Re: Re: NOT IN subquery optimization  (David Steele <david@pgmasters.net>)
Responses Re: NOT IN subquery optimization
List pgsql-hackers
On Tue, 5 Mar 2019 at 21:21, David Steele <david@pgmasters.net> wrote:
>
> On 2/27/19 2:26 AM, David Rowley wrote:
> > FWIW, I did add this to the March CF, but I set the target version to
> > 13.  I wasn't considering this for PG12. I see Zheng was, but I agree
> > with you on PG13 being the target for this.
>
> Looks like the target version of 13 was removed but I have added it back.

The problem seems to be that there are now 2 CF entries for this
thread. I originally added [1], but later Zheng added [2].  From what
Jim mentioned when he opened this thread I had the idea that no patch
existed yet, so I posted the one I already had written for this 4
years ago thinking that might be useful to base new work on.  I guess
Zheng's patch already exists when Jim opened this thread as a patch
appeared fairly quickly afterwards.  If that's true then I understand
that they wouldn't want to drop the work they'd already done in favour
of picking mine up.

I'm not all that sure what do to about this. It's going to cause quite
a bit of confusion having two patches in one thread. Part of me feels
that I've hijacked this thread and that I should just drop my patch
altogether and help review Zheng's patch, but I'm struggling a bit to
do that as I've not managed to find problems with my version, but a
few have been pointed out with the other patch  (of course, there may
be some yet undiscovered issues with my version too).

Alternatively, I could take my patch to another thread, but there does
not seem to be much sense in that. It might not solve the confusion
problem.  The best thing would be that if we could work together to
make this work, however, we both seem to have fairly different ideas
on how it should work. Tom and I both agree that Zheng and Jim's
proposal to add OR x IS NULL clauses to the join condition is most
likely a no go area due to it disallowing hash and merge anti-joins.
The last I can understand from Jim is that they appear to disagree
with that and want to do the transformation based on costs.  Perhaps
they're working on some new ideas to make that more feasible. I'm
interested to hear the latest on this.

[1] https://commitfest.postgresql.org/22/2020/
[2] https://commitfest.postgresql.org/22/2023/

--
 David Rowley                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services


pgsql-hackers by date:

Previous
From: David Steele
Date:
Subject: Re: Re: [HACKERS] [PROPOSAL] Temporal query processing with rangetypes
Next
From: "Iwata, Aya"
Date:
Subject: RE: libpq debug log