Re: quieting DEBUG3

On Wed, Oct 28, 2015 at 5:26 PM, Jeff Janes <jeff(dot)janes(at)gmail(dot)com> wrote:
> I figured it would go something like this:
>
> DEBUG1 once or a few times per statement/autovac/checkpoint
> DEBUG2 several times per statement/autovac/checkpoint (like once per
> joined relation in the planner)
> DEBUG3 once or a few times per row/block
> DEBUG4 several times per row/block
> DEBUG5 memory allocation.

I feel like this fails to take account of things that often don't
occur at all. On this scale, the messages I'm complaining about could
justifiably be DEBUG1 rather than DEBUG3, which would render all of
the DEBUG levels essentially useless. How about this: imagine a
reasonably busy system processing a thousand queries or so per second,
and consider log volume:

A given DEBUG1 message shouldn't fire more than ~1/sec.
A given DEBUG2 message shouldn't fire more than ~10/sec
A given DEBUG3 message shouldn't fire more than ~100/sec
A given DEBUG4 message shouldn't fire more than ~1000/sec
Anything which fires more than ~1000/s is DEBUG5

On this scale, most of the debug messages that the system actually
generates today are fine at their current levels - some of the DEBUG4
stuff could probably be bumped up to higher levels. But the messages
I'm complaining about are at least one level too high.

Another point I want to reiterate - because nobody seems to be
addressing it - is that some of these messages are totally useless. I
grant that printing the transaction state (XIDs, CIDs, etc.) is
useful. But does anybody really think that it's useful for every
statement to *additionally* generate DEBUG: CommitTransactionCommand?
Who looks at that? What value does it have? We do not print a
message when any other function that is called for every query is
entered - why that one? Whether we adjust the log levels of the
messages we have or not, we surely ought to get rid of the ones that
are useless clutter. Can anyone think of a single instance in which
that particular message has been useful in debugging ... anything?

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company