Re: Memoize ANTI and SEMI JOIN inner
От | Andrei Lepikhov |
---|---|
Тема | Re: Memoize ANTI and SEMI JOIN inner |
Дата | |
Msg-id | da135789-dcaf-49a6-9d05-25b68f1f72c5@gmail.com обсуждение исходный текст |
Ответ на | Re: Memoize ANTI and SEMI JOIN inner (David Rowley <dgrowleyml@gmail.com>) |
Ответы |
Re: Memoize ANTI and SEMI JOIN inner
|
Список | pgsql-hackers |
On 20/3/2025 07:02, David Rowley wrote: > On Thu, 20 Mar 2025 at 06:16, Andrei Lepikhov <lepihov@gmail.com> wrote: >> How can we be sure that semi or anti-join needs only one tuple? I think >> it would be enough to control the absence of join clauses and filters in >> the join. Unfortunately, we only have such a guarantee in the plan >> creation stage (maybe even setrefs.c). So, it seems we need to invent an >> approach like AlternativeSubplan. > > I suggest looking at what 9e215378d did. You might be able to also > allow semi and anti-joins providing the cache keys cover the entire > join condition. I think this might be safe as Nested Loop will only > ask its inner subnode for the first match before skipping to the next > outer row and with anti-join, there's no reason to look for additional > rows after the first. Semi-join and unique joins do the same thing in > nodeNestloop.c. To save doing additional checks at run-time, the code > does: Thank you for the clue! I almost took the wrong direction. I have attached the new patch, which includes corrected comments for better clarification of the changes, as well as some additional tests. I now feel much more confident about this version since I have resolved that concern. -- regards, Andrei Lepikhov
Вложения
В списке pgsql-hackers по дате отправления: