On Wed, Oct 28, 2015 at 5:26 PM, Jeff Janes <jeff.ja...@gmail.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
