Re: Curious why planner can't handle NOT IN

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

In response to

Browse pgsql-general by date

  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