Re: enable_joinremoval

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(at)2ndQuadrant(dot)com www.2ndQuadrant.us