On Wed, Jul 04, 2007 at 11:09:19AM +0100, Heikki Linnakangas wrote:
> The only benefit I can see is that it moves the write() of a page out of
> the critical path. But as long as the OS cache can absorb the write, it
> should be very cheap compared to doing real I/O. Apparently the workload
> that benefits most is an OLTP workload where response times are
> critical, on a database that doesn't fit in share_buffers, but fits in
> OS cache.
I thought the point was to make checkpoints cheaper. Sure, the OS can
probably absorb the write() but you execute a fsync() shortly after so
you're going to block on that. The point being that by executing the
writes earlier you can get some of the writing done in the bakcground
prior to the fsync.
So it would be targetting people with lots of dirty shared buffers
where a checkpoint is going to eat your I/O bandwidth. An fsync will
make the OS write everything ASAP.
Have a nice day,
--
Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/
> From each according to his ability. To each according to his ability to litigate.
