Martijn van Oosterhout wrote:
> 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.
That was the purpose of the bgwriter "all"-scan. It was removed as part
of the load distributed checkpoints patch, as it's not needed anymore.
What's the purpose of the lru-scan?
-- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com