Re: our buffer replacement strategy is kind of lame

Поиск
Список
Период
Сортировка
От Greg Stark
Тема Re: our buffer replacement strategy is kind of lame
Дата
Msg-id CAM-w4HMZ7cfMM2udWmramrUKgoY7M4DGYKLTRM0xogA2M=H6wA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: our buffer replacement strategy is kind of lame  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: our buffer replacement strategy is kind of lame  (Robert Haas <robertmhaas@gmail.com>)
Re: our buffer replacement strategy is kind of lame  (Martijn van Oosterhout <kleptog@svana.org>)
Re: our buffer replacement strategy is kind of lame  (Jim Nasby <jim@nasby.net>)
Список 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 по дате отправления:

Предыдущее
От: Kääriäinen Anssi
Дата:
Сообщение: Re: index-only scans
Следующее
От: Heikki Linnakangas
Дата:
Сообщение: Re: index-only scans