Skip site navigation (1) Skip section navigation (2)

Re: Really dumb planner decision

From: Merlin Moncure <mmoncure(at)gmail(dot)com>
To: Matthew Wakeling <matthew(at)flymine(dot)org>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Grzegorz Jaśkiewicz <gryzman(at)gmail(dot)com>, pgsql-performance(at)postgresql(dot)org
Subject: Re: Really dumb planner decision
Date: 2009-04-16 12:11:30
Message-ID: b42b73150904160511t3ccaf2a9k3b4e64f0272e6b2@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-performance
On Thu, Apr 16, 2009 at 8:05 AM, Matthew Wakeling <matthew(at)flymine(dot)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

In response to

Responses

pgsql-performance by date

Next:From: Tom LaneDate: 2009-04-16 13:49:28
Subject: Re: Really dumb planner decision
Previous:From: Merlin MoncureDate: 2009-04-16 12:06:13
Subject: Re: Shouldn't the planner have a higher cost for reverse index scans?

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group