> Its certainly not useful to *me* in its current form. It would > produce way to much (usless) output. However if it were tied to > log_min_duration_statement so I get auto explains for long running > queries... That would be very useful indeed. Even if it has to > explain everything just to toss out the explain if it did not meet > log_min_duration_statement. Unless I missed something and thats > exactly what it does?
Thanks for the feedback. I agree, it does need a way to limit the output, and target just the slow-running queries. I also remember now the problem I had last time:- since this debug output is produced at a lower level than the other statement logging (so it can explain *all* SQL executed, not just top-level statements), it is difficult to control using the normal statement logging parameters. It would be easy to add another parameter, debug_explain_min_duration, specific to this option, to limit it to slow low-level queries. This would allow setting debug_explain_min_duration to be smaller than log_min_duration_statement, which makes sense, since the latter controls logging of top-level statements which may result in multiple low-level queries. Doing it this way would mean instrumenting all queries, but only explaining the slow ones, when debug_explain_plan is on. I'll have a play and see how it goes... Regards, Dean _________________________________________________________________ Live Search Charades - guess correctly and find hidden videos http://www.searchcharades.com/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
