From: Clemens Eisserer <linuxhippy@gmail.com>
To: pgsql-performance@postgresql.org
Subject: Re: hash semi join caused by "IN (select ...)"
Date: Wed, 18 May 2011 10:46:00 +0200
Message-ID: <BANLkTikuKT0AMio56cRrDzp6r8SWSyxTWg@mail.gmail.com> (raw)
In-Reply-To: <BANLkTiky98A60cJ85mbTk4iuWBQYpyJgLg@mail.gmail.com>
References: <BANLkTikR6ngJS9=e1e1yA+E0FyxuJY_i3A@mail.gmail.com>
<23922.1305588168@sss.pgh.pa.us>
<BANLkTiky98A60cJ85mbTk4iuWBQYpyJgLg@mail.gmail.com>
Hi,
Does anybody know why the planner treats "= ANY(ARRAY(select ...))"
differently than "IN(select ...)"?
Which one is preferable, when I already have a lot of joins?
Thanks, Clemens
2011/5/17 Clemens Eisserer <linuxhippy@gmail.com>:
> Hi,
>
>>> select .... from t1 left join t2 .... WHERE id IN (select ....)
>>
>> Does it work as expected with one less join? If so, try increasing
>> join_collapse_limit ...
>
> That did the trick - thanks a lot. I only had to increase
> join_collapse_limit a bit and now get an almost perfect plan.
> Instead of hash-joining all the data, the planner generates
> nested-loop-joins with index only on the few rows I fetch.
>
> Using = ANY(array(select... )) also seems to work, I wonder which one
> works better. Does ANY(ARRAY(...)) force the optimizer to plan the
> subquery seperated from the main query?
>
> Thanks, Clemens
>
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: linuxhippy@gmail.com
Subject: Re: hash semi join caused by "IN (select ...)"
In-Reply-To: <BANLkTikuKT0AMio56cRrDzp6r8SWSyxTWg@mail.gmail.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox