From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Ole Tange <postgresql(dot)org(at)tange(dot)dk>, "pgsql-bugs(at)postgresql(dot)org" <pgsql-bugs(at)postgresql(dot)org> |
Subject: | Re: BUG #4949: NOT IN is prohibitive slower than the rewrite for medium to large sets |
Date: | 2009-07-29 02:05:04 |
Message-ID: | EA4D8D0C-7603-4C59-BCB9-0F0B1A04BE5E@gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
On Jul 28, 2009, at 9:47 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> "Ole Tange" <postgresql(dot)org(at)tange(dot)dk> writes:
>> (modulo NULLs which seem to always cause problems in NOT INs).
>
>> Because it can be rewritten, NOT IN should never be much slower
>> than the
>> rewritten solution, as PostgreSQL should simply rewrite NOT IN to the
>> above.
>
> Let's see, you understand that the rewrite violates the SQL standard
> semantics of NOT IN, but you think we should do it anyway?
If the subquery can't return NULLs, the rewrite is valid. I know
you've rejected the idea of checking for this in the past, but perhaps
you should consider this a user vote in favor of doing so.
I learned the hard way not to do this >5 years ago but it seemed
strange to me, too.
...Robert
From | Date | Subject | |
---|---|---|---|
Next Message | Craig Ringer | 2009-07-29 02:55:21 | Re: BUG #4945: Parallel update(s) gone wild |
Previous Message | Robert Haas | 2009-07-29 01:20:11 | Re: BUG #4945: Parallel update(s) gone wild |