Re: not in(subselect) in 8.4

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Scott Carey <scott(at)richrelevance(dot)com>
Cc: Grzegorz Jaśkiewicz <gryzman(at)gmail(dot)com>, "pgsql-performance(at)postgresql(dot)org" <pgsql-performance(at)postgresql(dot)org>
Subject: Re: not in(subselect) in 8.4
Date: 2009-02-22 03:41:41
Message-ID: 4043.1235274101@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

Scott Carey <scott(at)richrelevance(dot)com> writes:
> Are there any optimizations planned for the case where columns are
> defined as NOT NULL?

We might get around to recognizing that case as an antijoin sometime.
It's nontrivial though, because you have to check for an intermediate
outer join causing the column to be possibly nullable after all.

> It turns out to be a rare use case for someone to write a subselect
> for a NOT IN or IN clause that will have NULL values.

Judging from the steady flow of "why doesn't my NOT IN query work"
newbie questions, I don't think it's so rare as all that.

There's surely some population of people who know enough or could be
trained to be careful about using NOT NULL columns, but they could also
be trained to use NOT EXISTS, and dodge the whole bullet from the start.

regards, tom lane

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Robert Haas 2009-02-22 04:39:49 Re: not in(subselect) in 8.4
Previous Message Jonah H. Harris 2009-02-22 02:04:49 Re: Benchmark comparing PostgreSQL, MySQL and Oracle