On Mon, Mar 29, 2010 at 12:03 PM, Greg Smith <g...@2ndquadrant.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
