Re: hash semi join caused by "IN (select ...)" - Mailing list pgsql-performance

From Clemens Eisserer
Subject Re: hash semi join caused by "IN (select ...)"
Date
Msg-id BANLkTiky98A60cJ85mbTk4iuWBQYpyJgLg@mail.gmail.com
Whole thread Raw
In response to Re: hash semi join caused by "IN (select ...)"  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: hash semi join caused by "IN (select ...)"  (Clemens Eisserer <linuxhippy@gmail.com>)
Re: hash semi join caused by "IN (select ...)"  (Scott Carey <scott@richrelevance.com>)
List 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

pgsql-performance by date:

Previous
From: Robert Klemme
Date:
Subject: Re: [PERFORMANCE] expanding to SAN: which portion best to move
Next
From: Craig Ringer
Date:
Subject: Re: [PERFORMANCE] expanding to SAN: which portion best to move