From: | Grzegorz Jaśkiewicz <gryzman(at)gmail(dot)com> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
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-17 20:05:28 |
Message-ID: | 2f4958ff0912171205p4ed4e46ct903680be334b934@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
On Thu, Dec 17, 2009 at 6:05 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> On Thu, Dec 17, 2009 at 10:23 AM, Thomas Hamilton
> <thomashamilton76(at)yahoo(dot)com> wrote:
>> Apparently the latest version of MySQL has solved this problem: http://www.xaprb.com/blog/2006/06/28/why-large-in-clauses-are-problematic/
>>
>> But I am running PostgreSQL v8.3 and am observing generally that SELECT ... WHERE ... IN (a, b, c, ...) is much slower than SELECT ... INNER JOIN (SELECT a UNION ALL SELECT b UNION ALL SELECT c ...)
>
> That's certainly not MY observation. It would be interesting to see
> what's going on in your case but you'll need to provide more details.
>
> http://wiki.postgresql.org/wiki/Guide_to_reporting_problems
>
I asked the same question many times, and answer was always the same -
there's no point in doing that...
well... I've been asked by folks at work, the same thing (for typical
engineer, grasping the idea of join can be hard sometimes...).
--
GJ
From | Date | Subject | |
---|---|---|---|
Next Message | Karl Larsson | 2009-12-17 23:22:15 | seq scan instead of index scan |
Previous Message | Robert Haas | 2009-12-17 18:05:28 | Re: Automatic optimization of IN clauses via INNER JOIN |