Re: Controlling Load Distributed Checkpoints

Decibel! <decibel@decibel.org>

From: "Jim C. Nasby" <decibel@decibel.org>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Heikki Linnakangas <heikki@enterprisedb.com>, PostgreSQL-development <pgsql-hackers@postgresql.org>, Greg Smith <gsmith@gregsmith.com>, Hannu Krosing <hannu@skype.net>, ITAGAKI Takahiro <itagaki.takahiro@oss.ntt.co.jp>, Greg Stark <greg.stark@enterprisedb.com>
Date: 2007-06-09T07:39:19Z
Lists: pgsql-hackers
On Thu, Jun 07, 2007 at 10:16:25AM -0400, Tom Lane wrote:
> Heikki Linnakangas <heikki@enterprisedb.com> writes:
> > Thinking about this whole idea a bit more, it occured to me that the 
> > current approach to write all, then fsync all is really a historical 
> > artifact of the fact that we used to use the system-wide sync call 
> > instead of fsyncs to flush the pages to disk. That might not be the best 
> > way to do things in the new load-distributed-checkpoint world.
> 
> > How about interleaving the writes with the fsyncs?
> 
> I don't think it's a historical artifact at all: it's a valid reflection
> of the fact that we don't know enough about disk layout to do low-level
> I/O scheduling.  Issuing more fsyncs than necessary will do little
> except guarantee a less-than-optimal scheduling of the writes.

If we extended relations by more than 8k at a time, we would know a lot
more about disk layout, at least on filesystems with a decent amount of
free space.
-- 
Jim Nasby                                      decibel@decibel.org
EnterpriseDB      http://enterprisedb.com      512.569.9461 (cell)