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

---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

Reply via email to