From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Dirschel, Steve" <steve(dot)dirschel(at)thomsonreuters(dot)com> |
Cc: | "pgsql-general(at)lists(dot)postgresql(dot)org" <pgsql-general(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Postgres NOT IN vs NOT EXISTS optimization |
Date: | 2022-06-14 16:09:16 |
Message-ID: | 76344.1655222956@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general pgsql-hackers |
"Dirschel, Steve" <steve(dot)dirschel(at)thomsonreuters(dot)com> writes:
> Is Postgres able to drive the query the same way with the NOT IN as the
> NOT EXISTS is doing or is that only available if the query has a NOT
> EXISTS?
NOT IN is not optimized very well in PG, because of the strange
semantics that the SQL spec demands when the sub-query produces any
null values. There's been some interest in detecting cases where
we can prove that the subquery produces no nulls and then optimizing
it into NOT EXISTS, but it seems like a lot of work for not-great
return, so nothing's happened (yet). Perhaps Oracle does something
like that already, or perhaps they're just ignoring the semantics
problem; they do not have a reputation for hewing closely to the
spec on behavior regarding nulls.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Daniel Brinzila | 2022-06-14 19:30:47 | Recent 11.16 release change |
Previous Message | Jeremy Smith | 2022-06-14 16:06:52 | Re: Postgres NOT IN vs NOT EXISTS optimization |
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Geoghegan | 2022-06-14 16:10:03 | Re: better page-level checksums |
Previous Message | Andrew Dunstan | 2022-06-14 16:08:16 | Small TAP improvements |