Date: Wed, 30 May 2007 00:09:29 -0400 (EDT)
From: Greg Smith <gsmith@gregsmith.com>
To: pgsql-patches@postgresql.org
Subject: Re: Logging checkpoints and other slowdown causes
In-Reply-To: <465C6932.4070800@enterprisedb.com>
Message-ID: <Pine.GSO.4.64.0705292337150.12775@westnet.com>
References: <Pine.GSO.4.64.0704010051050.14920@westnet.com>
	<200704030814.33999.peter_e@gmx.net>
	<Pine.GSO.4.64.0704030927180.5732@westnet.com>
	<46443F02.6060300@enterprisedb.com>
	<Pine.GSO.4.64.0705111009080.18685@westnet.com>
	<465B3ABB.6010709@enterprisedb.com>
	<Pine.GSO.4.64.0705282200190.28443@westnet.com>
	<465C6932.4070800@enterprisedb.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed

On Tue, 29 May 2007, Heikki Linnakangas wrote:

> The checkpoint will take at least a couple of seconds on any interesting 
> system, so 0.1 s resolution should be enough IMHO.

You may be underestimating the resources some interesting systems are 
willing to put into speeding up checkpoints.  I'm sometimes dumping into a 
SAN whose cache is bigger than the shared_buffer cache in the server, and 
0.1s isn't really enough resolution in that situation.  A second is a 
really long checkpoint there.  Since even that's limited by fiber-channel 
speeds, I know it's possible to do better than what I'm seeing with 
something like a PCIe host adapter having on-board cache in the GB range 
(which isn't that expensive nowadays).

Also, even if the checkpoint total takes seconds, much of that is in the 
sync phase; the write time can still be in the small number of ms range, 
and I wouldn't want to see that truncated too much.

Anyway, I have a bunch of data on this subject being collected at this 
moment, and I'll rescale the results based on what I see after analyzing 
that this week.

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