agora inbox for pgsql-hackers@postgresql.org
help / color / mirror / Atom feedFrom: Greg Smith <greg@2ndquadrant.com>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Simon Riggs <simon@2ndquadrant.com>
Cc: pgsql-hackers@postgresql.org
Subject: Re: enable_joinremoval
Date: Mon, 29 Mar 2010 12:03:09 -0400
Message-ID: <4BB0CF3D.8090701@2ndquadrant.com> (raw)
In-Reply-To: <603c8f071003290820h3553d223le3b5228f789608f9@mail.gmail.com>
References: <1269851630.3684.3636.camel@ebony>
<603c8f071003290637q14d431f7j90afabd6fd2ec952@mail.gmail.com>
<12679.1269873374@sss.pgh.pa.us>
<603c8f071003290820h3553d223le3b5228f789608f9@mail.gmail.com>
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. 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?"
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.
--
Greg Smith 2ndQuadrant US Baltimore, MD
PostgreSQL Training, Services and Support
greg@2ndQuadrant.com www.2ndQuadrant.us
view thread (31+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: greg@2ndquadrant.com, robertmhaas@gmail.com, tgl@sss.pgh.pa.us, simon@2ndquadrant.com
Subject: Re: enable_joinremoval
In-Reply-To: <4BB0CF3D.8090701@2ndquadrant.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox