Re: our buffer replacement strategy is kind of lame - Mailing list pgsql-hackers

From Greg Stark
Subject Re: our buffer replacement strategy is kind of lame
Date
Msg-id CAM-w4HMZ7cfMM2udWmramrUKgoY7M4DGYKLTRM0xogA2M=H6wA@mail.gmail.com
Whole thread Raw
In response to Re: our buffer replacement strategy is kind of lame  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: our buffer replacement strategy is kind of lame
Re: our buffer replacement strategy is kind of lame
Re: our buffer replacement strategy is kind of lame
List pgsql-hackers
On Sat, Aug 13, 2011 at 8:52 PM, Robert Haas <robertmhaas@gmail.com> wrote:

> and possibly we ought to put them all in a
> linked list so that the next guy who needs a buffer can just pop one

The whole point of the clock sweep algorithm is to approximate an LRU
without needing to maintain a linked list. The problem with a linked
list is that you need to serialize access to it so every time you
reference a buffer you need to wait on a lock for the list so you can
move that buffer around in the list.

It does kind of seem like your numbers indicate we're missing part of
the picture though. The idea with the clock sweep algorithm is that
you keep approximately 1/nth of the buffers with each of the n values.
If we're allowing nearly all the buffers to reach a reference count of
5 then you're right that we've lost any information about which
buffers have been referenced most recently.

I wonder if we're suppoesd to be doing something like advancing the
clock hand each time we increment a reference count as well?


-- 
greg


pgsql-hackers by date:

Previous
From: Kääriäinen Anssi
Date:
Subject: Re: index-only scans
Next
From: Heikki Linnakangas
Date:
Subject: Re: index-only scans