On Mon, 2006-02-06 at 13:28 +0100, Csaba Nagy wrote:
> For me the usage pattern would be: log all params, bind time values, on
> the same log line as "log_min_duration" entries. That's what I need to
> know which are the non-performant queries, and it also helps on
> occasions to identify application problems.
You remind me that two sets of parameters could be logged
Trouble is, you need to know both
- parameters that were used to plan the query
- parameters used for this execution of the query
since very often it is the combination that is the problem. i.e. it was
a good query at plan time and if re-planned would also be a good query,
but running the earlier plan with the later set of parameters is bad.
Perhaps it would be useful to store the parameters that were used to
plan the query with the portal, so we could have an option to say "and
with what parameters was this query planned". That would then sensibly
appear on the log_min_messages log line, as you suggest. This is
important for diagnosing many run-time issues accurately.
Maybe we should expand the list to
log_parameters = none | bind | plan | exec | all
bind = log parameters directly at bind time, using a separate log line;
do not store them. Useful mainly as an interface debugging aid.
plan = store parameters used for planning with portal, then output them
with the statement at log_min_message time
e.g. (plan parms: p1= p2= ...) - which is very similar to what we do now
with spitting out the SQL statement since that is not resent for each
execution
exec = store the parameters used at bind time and output them with the
statement e.g. (exec parms: p1= p2=)
all = store the parameters used at bind time and output them with the
statement, as well as the exec parms e.g. (plan parms: p1= p2= ...)(exec
parms: p1= p2=)
none = nada, not even the current log lines for bind
Sounds too much, but you don't really want all of that all of the time.
Best Regards, Simon Riggs
