From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Greg Smith <greg(at)2ndquadrant(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Simon Riggs <simon(at)2ndquadrant(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: enable_joinremoval |
Date: | 2010-03-29 16:10:16 |
Message-ID: | 603c8f071003290910l310c0e18v6b8986a22c6c4836@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Mar 29, 2010 at 12:03 PM, Greg Smith <greg(at)2ndquadrant(dot)com> wrote:
> Robert Haas wrote:
>>
>> The query planner is a great piece of code but it
>> is not so transparently simple that it doesn't need debugging or
>> instrumentation, and "why did the planner do X" has got to be one of
>> our top ten most-frequently asked questions.
>
> Debugging and instrumentation are two slightly different issues.
Yeah, you're right. This is debugging, not instrumentation.
> There is a
> lot more instrumentation needed in the query optimizer before people have
> better odds of understanding what's going on in this part of the database.
> Recent features like pg_stat_statements and auto_explain are just the first
> round of what people really want here. Now that we can get the explain data
> out in usable formats (XML, JSON, YAML) for a tool to manage them, the thing
> at the top of my list in this area for 9.1 is to track down the rumored
> patch that exports information about the rejected plans considered and get
> that comitted. That always seems what I want to look at for answering the
> question "why this plan instead of what I was expecting?"
Having looked at that patch, I am skeptical of it, but we can
certainly take a fresh look.
> Stepping away from that, from the debugging perspective it seems one way to
> answer the question "is this unexpected behavior being caused by the new
> join removal code or not?" is to provide a way to toggle it off and see what
> changes. Much like enable_seqscan, just because we don't ever want people
> to use it in production doesn't necessarily mean it's a bad idea to expose
> it.
>
> Also, given that this is a complicated feature, I think it's reasonable to
> ask whether allowing it to be turned off is the right thing just from the
> pragmatic basis that it provides a, ahem, backup plan in case there's
> unexpected difficulty with it in the field.
Yep.
...Robert
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2010-03-29 16:17:54 | Re: enable_joinremoval |
Previous Message | Robert Haas | 2010-03-29 16:06:28 | Re: Proposal: Add JSON support |