> 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/
--=20
Sent via pgsql-hackers mailing list (pgsql-hackers@[EMAIL PROTECTED]
)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
|
