Re: Background LRU Writer/free list

From: Greg Smith <gsmith(at)gregsmith(dot)com>
To: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Background LRU Writer/free list
Date: 2007-04-19 02:57:08
Message-ID: Pine.GSO.4.64.0704182048190.18788@westnet.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, 18 Apr 2007, Tom Lane wrote:

> Furthermore, if the page was dirty, then it's probably been accessed
> more recently than adjacent pages that are clean, so preferentially
> zapping just-written pages seems backwards.

The LRU background writer only writes out pages that have a usage_count of
0, so they can't haven't been accessed too recently. Assuming the buffer
allocation rate continues its historical trend, these are the pages that
are going to be written out and then allocated for something new one way
or another in the next interval; the content is expected to be lost
shortly no matter what.

As for preferring dirty pages over clean ones, on a re-read my question
wasn't as clear as I wanted to be. I think that clean pages near the
strategy point should also be moved to the free list by the background
writer. You know clients are expected to require x buffers in the next y
ms based on the history of the server (the new piece of information
provided by the patch in the queue), and the LRU background writer is
working in advance to make them available. If you're doing all that,
doesn't it make sense to finish the job by putting the pages on the free
list, where the clients can grab them without running their own scan over
the buffer cache?

--
* Greg Smith gsmith(at)gregsmith(dot)com http://www.gregsmith.com Baltimore, MD

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Greg Smith 2007-04-19 03:04:04 Re: Background LRU Writer/free list
Previous Message Martin Langhoff 2007-04-19 01:20:43 Re: Hacking on PostgreSQL via GIT