Re: Controlling Load Distributed Checkpoints - Mailing list pgsql-hackers

From Heikki Linnakangas
Subject Re: Controlling Load Distributed Checkpoints
Date
Msg-id 46683F1D.4060609@enterprisedb.com
Whole thread Raw
In response to Re: Controlling Load Distributed Checkpoints  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Controlling Load Distributed Checkpoints  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
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.

I'm not proposing to issue any more fsyncs. I'm proposing to change the 
ordering so that instead of first writing all dirty buffers and then 
fsyncing all files, we'd write all buffers belonging to a file, fsync 
that file only, then write all buffers belonging to next file, fsync, 
and so forth.

--   Heikki Linnakangas  EnterpriseDB   http://www.enterprisedb.com


pgsql-hackers by date:

Previous
From: "Matthew T. O'Connor"
Date:
Subject: Re: [PATCHES] [BUGS] BUG #3326: Invalid lower bound of autovacuum_cost_limit
Next
From: Tom Lane
Date:
Subject: Re: Controlling Load Distributed Checkpoints