Re: why "WHERE uid NOT IN" is so slow, and EXCEPT in the same situtation is fast?
От | Tom Lane |
---|---|
Тема | Re: why "WHERE uid NOT IN" is so slow, and EXCEPT in the same situtation is fast? |
Дата | |
Msg-id | 27820.1217473686@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | why "WHERE uid NOT IN" is so slow, and EXCEPT in the same situtation is fast? (Miernik <public@public.miernik.name>) |
Ответы |
Re: why "WHERE uid NOT IN" is so slow, and EXCEPT in the
same situtation is fast?
|
Список | pgsql-performance |
Miernik <public@public.miernik.name> writes: > Two queries which do the same thing, first one takes ages to complete > (did wait several minutes and cancelled it), while the second one took > 9 seconds? Don't they do the same thing? Hmm, what have you got work_mem set to? The first one would likely have been a lot faster if it had hashed the subplan; which I'd have thought would happen with only 80K rows in the subplan result, except it didn't. The queries are in fact not exactly equivalent, because EXCEPT involves some duplicate-elimination behavior that won't happen in the NOT IN formulation. So I don't apologize for your having gotten different plans. But you should have gotten a plan less awful than that one for the NOT IN. Another issue is that the NOT IN will probably not do what you expected if the subquery yields any NULLs. regards, tom lane
В списке pgsql-performance по дате отправления: