From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Yang Zhang <yanghatespam(at)gmail(dot)com> |
Cc: | "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: Curious why planner can't handle NOT IN |
Date: | 2013-05-03 14:29:30 |
Message-ID: | 23632.1367591370@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Yang Zhang <yanghatespam(at)gmail(dot)com> writes:
> The most obvious query doesn't work so hot due to repeated execution
> of the subplan:
> => explain insert into newaccount select * from account where id not
> in (select id from account);
Yeah. Try using a NOT EXISTS instead.
> This isn't a big deal as there's a straightforward workaround, but I
> am curious what happened here. Googling turns up various mentions of
> "NOT IN" with poor plans that involve subplans. Then again I have
> read mention of hash anti-join which seems appropriate here(?), but
> that wasn't used here
The trouble with NOT IN is that it's not exactly the same as an
antijoin, because of the spec-mandated bizarre behavior for NULLs.
It's very difficult to optimize it to any extent without producing
wrong answers. NOT EXISTS avoids that problem.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2013-05-03 14:42:53 | Re: SPI_execute_with_args call |
Previous Message | Yuriy Rusinov | 2013-05-03 10:56:55 | Re: SPI_execute_with_args call |