Re: Design notes for BufMgrLock rewrite - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: Design notes for BufMgrLock rewrite
Date
Msg-id 200502210419.j1L4J0613918@candle.pha.pa.us
Whole thread Raw
In response to Re: Design notes for BufMgrLock rewrite  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Tom Lane wrote:
> "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?

One idea would be for the clock to check X% of the buffer cache and just
recycle the page it saw with the lowest usage count.

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
359-1001+  If your life is a hard drive,     |  13 Roberts Road +  Christ can be your backup.        |  Newtown Square,
Pennsylvania19073
 


pgsql-hackers by date:

Previous
From: Curt Sampson
Date:
Subject: Re: Time Zone Names Problem
Next
From: pgsql@mohawksoft.com
Date:
Subject: Re: Query optimizer 8.0.1 (and 8.0)