Re: Really dumb planner decision - Mailing list pgsql-performance

From Merlin Moncure
Subject Re: Really dumb planner decision
Date
Msg-id b42b73150904160511t3ccaf2a9k3b4e64f0272e6b2@mail.gmail.com
Whole thread Raw
In response to Re: Really dumb planner decision  (Matthew Wakeling <matthew@flymine.org>)
Responses Re: Really dumb planner decision
List pgsql-performance
On Thu, Apr 16, 2009 at 8:05 AM, Matthew Wakeling <matthew@flymine.org> wrote:
> On Thu, 16 Apr 2009, Robert Haas wrote:
>>
>> What happens if you change join_collapse_limit and from_collapse_limit
>> to some huge number?
>>
>>
>> http://www.postgresql.org/docs/current/static/runtime-config-query.html#GUC-FROM-COLLAPSE-LIMIT
>
> That solves the problem. So, a view is treated as a subquery then?
>

no...the view is simply inlined into the query (think C macro) using
the rules.  You just bumped into an arbitrary (and probably too low)
limit into the number of tables the planner can look at in terms of
optimizing certain types of plans.  It's the first thing to look at
when you add tables to a big query and performance falls off a cliff
when it shouldn't.

merlin

pgsql-performance by date:

Previous
From: Merlin Moncure
Date:
Subject: Re: Shouldn't the planner have a higher cost for reverse index scans?
Next
From: Tom Lane
Date:
Subject: Re: Really dumb planner decision