Date: Fri, 7 Dec 2007 22:25:46 -0500 (EST)
From: Greg Smith <gsmith@gregsmith.com>
cc: pgsql-docs@postgresql.org, pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] "distributed checkpoint"
In-Reply-To: <1197051730.4255.603.camel@ebony.site>
Message-ID: <Pine.GSO.4.64.0712072138270.10014@westnet.com>
References: <20071206220348.GM8451@alvh.no-ip.org>
	<5958.1196991889@sss.pgh.pa.us>
	<20071206191944.1d7926d2@commandprompt.com>
	<20071207034328.GB18310@fetter.org>
	<1197051730.4255.603.camel@ebony.site>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed

On Fri, 7 Dec 2007, Simon Riggs wrote:

> "Smoothed" makes a lot of sense for me. We used to have a checkpoint
> spike, now we don't.

To be accurate, there used to be a huge and unavoidable spike, now there's 
a control that aims to make it smaller.  The problem hasn't completely 
gone away yet.

With that in mind, let me start over.  Here's what's in the release notes 
right now:

"Distributed checkpoints prevent I/O spikes during checkpoints"

It's good this came up, because that is factually wrong; while the average 
case is much better some OS-dependant aspects of the spike (what happens 
at fsync) are certainly still there.  I think it's easier to rewrite this 
whole thing so it's technically accurate rather than a simple fix of the 
wording, something like this:

"Checkpoint writes can be spread over a longer time period to smooth the 
I/O spike during each checkpoint"

It's got spread, it's got smooth, and if I could have worked "silky" in 
there too I would have.

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