Re: Design notes for BufMgrLock rewrite

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Design notes for BufMgrLock rewrite
Дата
Msg-id 25460.1108575218@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Design notes for BufMgrLock rewrite  ("Jim C. Nasby" <decibel@decibel.org>)
Ответы Re: Design notes for BufMgrLock rewrite  (Kenneth Marshall <ktm@it.is.rice.edu>)
Re: Design notes for BufMgrLock rewrite  (Richard Huxton <dev@archonet.com>)
Re: Design notes for BufMgrLock rewrite  (Bruce Momjian <pgman@candle.pha.pa.us>)
Список pgsql-hackers
"Jim C. Nasby" <decibel@decibel.org> writes:
> The advantage of using a counter instead of a simple active
> bit is that buffers that are (or have been) used heavily will be able to
> go through several sweeps of the clock before being freed. Infrequently
> used buffers (such as those from a vacuum or seq.  scan), would get
> marked as inactive the first time they were hit by the clock hand.

Hmm.  It would certainly be nearly as easy to adjust a counter as to
manipulate the RECENTLY_USED flag bit that's in the patch now.  (You
could imagine the RECENTLY_USED flag bit as a counter with max value 1.)

What I'm envisioning is that pinning (actually unpinning) a buffer
increments the counter (up to some limit), and the clock sweep
decrements it (down to zero), and only buffers with count zero are taken
by the sweep for recycling.  That could work well, but I think the limit
needs to be relatively small, else we could have the clock sweep having
to go around many times before it finally frees a buffer.  Any thoughts
about that?  Anyone seen any papers about this sort of algorithm?
        regards, tom lane


В списке pgsql-hackers по дате отправления:

Предыдущее
От: pgsql@mohawksoft.com
Дата:
Сообщение: Re: Help me recovering data
Следующее
От: Stephan Szabo
Дата:
Сообщение: Re: Help me recovering data