Re: NOT IN subquery optimization

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: NOT IN subquery optimization
Дата
Msg-id 2284.1551482036@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: NOT IN subquery optimization  ("Li, Zheng" <zhelli@amazon.com>)
Ответы Re: NOT IN subquery optimization
Список pgsql-hackers
"Li, Zheng" <zhelli@amazon.com> writes:
> Although adding "or var is NULL" to the anti join condition forces the planner to choose nested loop anti join, it is
alwaysfaster compared to the original plan. 

TBH, I am *really* skeptical of sweeping claims like that.  The existing
code will typically produce a hashed-subplan plan, which ought not be
that awful as long as the subquery result doesn't blow out memory.
It certainly is going to beat a naive nested loop.

            regards, tom lane


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Why don't we have a small reserved OID range for patch revisions?
Следующее
От: David Rowley
Дата:
Сообщение: Re: NOT IN subquery optimization