Re: Re: NOT IN subquery optimization

Поиск
Список
Период
Сортировка
От David Rowley
Тема Re: Re: NOT IN subquery optimization
Дата
Msg-id CAKJS1f8b_X-WsjJcP5hw6sEj7DGwer4UPcVDFUPKiWO1RR5pvw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Re: NOT IN subquery optimization  (David Steele <david@pgmasters.net>)
Ответы Re: NOT IN subquery optimization
Список 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 по дате отправления:

Предыдущее
От: David Steele
Дата:
Сообщение: Re: Re: [HACKERS] [PROPOSAL] Temporal query processing with rangetypes
Следующее
От: "Iwata, Aya"
Дата:
Сообщение: RE: libpq debug log