| От | 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 по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера