Date: Tue, 3 Apr 2007 09:53:37 -0400 (EDT)
From: Greg Smith <gsmith@gregsmith.com>
To: pgsql-patches@postgresql.org
Subject: Re: Logging checkpoints and other slowdown causes
In-Reply-To: <200704030814.33999.peter_e@gmx.net>
Message-ID: <Pine.GSO.4.64.0704030927180.5732@westnet.com>
References: <Pine.GSO.4.64.0704010051050.14920@westnet.com>
	<200704030814.33999.peter_e@gmx.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed

On Tue, 3 Apr 2007, Peter Eisentraut wrote:

> Something that is aimed at a user should not be enabled at a "debug"
> level.  Debug levels are for debugging, not for very high verbosity.

I asked for feedback about where to log at when I intially sent the first 
version of this in and didn't hear anything back on that part, so I pushed 
these in line with other log messages I saw.  The messages for when 
checkpoints start and stop were both logged at DEBUG2, so I put progress 
reports on the other significant phases of the process there as well.

I don't expect these messages will be helpful for a normal user--that's 
what the new data in pg_stats_bgwriter is for.  Their main purpose of this 
patch is debugging checkpoint related performance issues at a level I'd 
expect only a developer to work at; they're also helpful for someone 
writing benchmark code.

There are several patches in process floating around that aim to adjust 
either the background writer or the checkpoint process to reduce the 
impact of checkpoints.  This logging allows grading their success at that. 
As my tests with this patch in place suggest this problem is far from 
solved with any of the current suggestions, I'd like to get other 
developers looking at that problem the same way I have been; that's why 
I'd like to see some standardization on how checkpoints are instrumented. 
The fact that really advanced users might also use this for 
troubleshooting I consider a bonus rather than the main focus here.

--
* Greg Smith gsmith@gregsmith.com http://www.gregsmith.com Baltimore, MD