Re: 8.0.0beta3 duration logging patch

On Tuesday September 28 2004 7:59, Tom Lane wrote:
> Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> 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