On Tuesday September 28 2004 7:59, Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Your issue brings up that the boolean API doesn't really work well, and
> > in fact highlights the fact that printing the duration as an
> > independent capability really made no sense at all. Perhaps your
> > approach is the proper solution --- to link them together.
>
> I thought we had fixed things so that log_duration would print the
> statement if it hadn't already been logged for other reasons. Did
> that fix get broken again?
I guess so. If you set log_min_statement_duration = 0, you get
"duration: %ld.%03ld ms statement: %s"
regardless of your log_duration or log_statement settings. But log_duration
does not heed log_statement, thus no way to quiet durations in sync with
log_statement setting. In beta3, the logic is...
if ( log_duration = true ||
(log_min_statement_duration = 0 ||
(log_min_statement_duration > 0 &&
duration > log_min_statement_duration)))
Going back to the issue of usefulness of queryless durations, I guess I can
imagine that if someone wanted to measure average duration similar to a
speedometer, they might want to log only durations, not queries, just to
know how hot the DB is running. I have a 7.3 perl script to do just that.
Maybe a better patch would be to make log_duration have the same options as
log_statement (none, mod, ddl, all)? That would preserve the previous
functionality and enable the more common usage as well. I would leave
log_min_statement_duration alone since I can see where it would be useful
to be able to visually distinguish between durations printed because they
exceeded log_min_statement_duration. For example, logging all
data-changing queries (mod) and also any overly slow SELECTs.
Ed
---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
