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
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 |