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 g...@2ndquadrant.com www.2ndQuadrant.us -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
