Re: problem with from_collapse_limit and joined views

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>
Cc: msc(at)antzsystem(dot)de, pgsql-performance(at)postgresql(dot)org
Subject: Re: problem with from_collapse_limit and joined views
Date: 2010-12-04 16:59:58
Message-ID: 24137.1291481998@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

"Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov> writes:
> Markus Schulz 11/24/10 1:02 PM >>>
>> if i set "from_collapse_limit" (to merge the views) and
>> join_collapse_limit (to explode the explicit joins) high enough
>> (approx 32), all is fine (good performance). But other queries are
>> really slow in our environment (therefore it's no option to raise
>> the join_collapse_limit to a higher value)
>>
>> With defaults (8) for both, the performance is ugly

> One option would be to create a different user for running queries
> which read from complex views such as this.

If you don't want to change the collapse limits, the only other option
is to restructure this specific query so that its syntactic structure
is closer to the ideal join order. Look at the plan you get in the
good-performing case and re-order the join syntax to look like that.

regards, tom lane

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Markus Schulz 2010-12-04 18:20:28 Re: problem with from_collapse_limit and joined views
Previous Message Tom Lane 2010-12-04 16:42:03 Re: Query-plan for partitioned UPDATE/DELETE slow and swaps vmem compared to SELECT