Re: [PERFORM] reducing random_page_cost from 4 to 2 to force index scan

Jim Nasby wrote: I think the challenge there would be how to define the scope of the hot-spot. Is it the last X pages? Last X serial values? Something like correlation? Hmm... it would be interesting if we had average relation access times for each stats bucket on a per-column basis; that woul

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

On 5/17/11 12:38 AM, "Clemens Eisserer" wrote: >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_colla

Re: [PERFORM] LIMIT and UNION ALL

Hello 2011/5/18 Dave Johansen : > I am using Postgres 8.3.3 and I have a VIEW which is a UNION ALL of two > tables but when I do a select on the view using a LIMIT, it scans the entire > tables and takes significantly longer than writing out the query with the > LIMITs in the sub-queries themselv

Re: [PERFORM] LIMIT and UNION ALL

On Wed, May 18, 2011 at 5:26 PM, Dave Johansen wrote: > I am using Postgres 8.3.3 and I have a VIEW which is a UNION ALL of two > tables but when I do a select on the view using a LIMIT, it scans the entire > tables and takes significantly longer than writing out the query with the > LIMITs in the

[PERFORM] LIMIT and UNION ALL

I am using Postgres 8.3.3 and I have a VIEW which is a UNION ALL of two tables but when I do a select on the view using a LIMIT, it scans the entire tables and takes significantly longer than writing out the query with the LIMITs in the sub-queries themselves. Is there a solution to get the view to

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

On Wed, May 18, 2011 at 1:46 AM, Clemens Eisserer wrote: > 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 : > > Hi, >

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

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 : > Hi, > >>> select from t1 left join t2 WHERE id IN (select ) >> >> D