| 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 |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| 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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2009-04-16 13:49:28 | Re: Really dumb planner decision |
| Previous Message | Merlin Moncure | 2009-04-16 12:06:13 | Re: Shouldn't the planner have a higher cost for reverse index scans? |