Ooops. That last patch had an embarrassing little typo which caused it to not
actually record the planner times.
This new version fixes that and also includes a little patch to psql so that it
ignores any backend notices during tab-completion, which otherwise just get
in the way. Trace during tab-completion still goes to the server log, if enabled,
since this might actually be useful for debugging psql.
> * trace_min_planner_duration - int, PGC_USERSET
> * trace_min_executor_duration - int, PGC_USERSET
> * trace_explain_plan - bool, PGC_USERSET
I'm toying with the idea of adding another parameter, just for convenience:
* auto_trace = on | off
If trace_min_planner_duration and trace_min_executor_duration are both -1,
then setting auto_trace=on would be equivalent to setting
trace_min_planner_duration=0, trace_min_executor_duration=0 and
trace_explain_plan=on, causing *all* statements to be timed and explained
(similar to Oracle's AUTOTRACE).
If either of trace_min_planner_duration or trace_min_executor_duration
are> -1, then auto_trace will do nothing, and only those queries that are
slow to plan and/or execute would be logged.
I'll hold off actually do any more with this for now though, because I feel
that there are still a couple of questions not fully answered:
* Is a whole new logging level (TRACE) overkill for this, or would it
potentially have other uses in the future? My feeling is that it works quite
* It it safe to open this up to ordinary users, or do more restrictions need
to be put on it, and if so what?
The John Lewis Clearance - save up to 50% with FREE delivery
pgsql-hackers by date
|Next:||From: Abhijit Menon-Sen||Date: 2008-07-11 10:02:16|
|Subject: Re: posix advises ...|
|Previous:||From: Simon Riggs||Date: 2008-07-11 07:34:34|
|Subject: Re: Schema-qualified statements in pg_dump output|