Re: hash semi join caused by "IN (select ...)"

From: Clemens Eisserer <linuxhippy(at)gmail(dot)com>
To: pgsql-performance(at)postgresql(dot)org
Subject: Re: hash semi join caused by "IN (select ...)"
Date: 2011-05-17 07:38:55
Message-ID: BANLkTiky98A60cJ85mbTk4iuWBQYpyJgLg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

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

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Craig Ringer 2011-05-17 09:47:09 Re: [PERFORMANCE] expanding to SAN: which portion best to move
Previous Message Robert Klemme 2011-05-17 07:00:31 Re: [PERFORMANCE] expanding to SAN: which portion best to move