Re: ACM Paper relevant to our buffer algorithm

From: Heikki Linnakangas <heikki(at)enterprisedb(dot)com>
To: Martijn van Oosterhout <kleptog(at)svana(dot)org>
Cc: Greg Smith <gsmith(at)gregsmith(dot)com>, PostgreSQL-development Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: ACM Paper relevant to our buffer algorithm
Date: 2007-07-04 10:39:11
Message-ID: 468B78CF.4040403@enterprisedb.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Dawid Kuroczko 2007-07-04 11:03:20 Idea: Comments on system catalogs?
Previous Message Martijn van Oosterhout 2007-07-04 10:37:07 Re: ACM Paper relevant to our buffer algorithm