| From: | Craig Ringer <craig(at)postnewspapers(dot)com(dot)au> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Thomas Hamilton <thomashamilton76(at)yahoo(dot)com>, pgsql-performance(at)postgresql(dot)org |
| Subject: | Re: Automatic optimization of IN clauses via INNER JOIN |
| Date: | 2009-12-18 02:20:14 |
| Message-ID: | 4B2AE6DE.206@postnewspapers.com.au |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
On 17/12/2009 11:57 PM, Tom Lane wrote:
> Thomas Hamilton<thomashamilton76(at)yahoo(dot)com> writes:
>> But in our testing under the same optimization and conditions INNER JOIN is significantly outperforming IN.
>
> [ shrug... ] You haven't provided any details, so it's impossible to
> offer any useful advice.
In other words: can we discuss this with reference to a specific case?
Please provide your queries, your EXPLAIN ANALYZE output, and other
relevant details as per:
http://wiki.postgresql.org/wiki/SlowQueryQuestions
I'd be interested in knowing whether the planner can perform such
transformations and if so why it doesn't myself. I have the vague
feeling there may be semantic differences in the handling of NULL but I
can't currently seem to puzzle them out.
--
Craig Ringer
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2009-12-18 06:27:11 | Re: seq scan instead of index scan |
| Previous Message | Scott Marlowe | 2009-12-18 01:37:36 | Re: seq scan instead of index scan |