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
