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

From Greg Stark
Subject Re: Design notes for BufMgrLock rewrite
Date
Msg-id 87bran680o.fsf@stark.xeocode.com
Whole thread Raw
In response to Re: Design notes for BufMgrLock rewrite  (Bruce Momjian <pgman@candle.pha.pa.us>)
List pgsql-hackers
Bruce Momjian <pgman@candle.pha.pa.us> writes:

> Tom Lane wrote:
> > 
> > One thing I realized quickly is that there is no natural way in a clock
> > algorithm to discourage VACUUM from blowing out the cache.  I came up
> > with a slightly ugly idea that's described below.  Can anyone do better?
> 
> Uh, is the clock algorithm also sequential-scan proof?  Is that
> something that needs to be done too?

I think the normal strategy is to make it *always* work the way you made
VACUUM work. That is, it should always enter newly loaded pages with the
"recently used" flag false.

It doesn't necessarily mean they get purged immediately on the next flush, any
other buffer that hasn't been accessed since it was loaded is also a
candidate, but if nothing else accesses it before the clock hand gets to it
then it a candidate.

The only thing that scares me about this is that running a vacuum or
sequential scan could have too much of an effect on non-sequential accesses
like index scans if it forced the hand around so fast that the index scan
didn't have a chance to reuse pages.

-- 
greg



pgsql-hackers by date:

Previous
From: Tzahi Fadida
Date:
Subject: Re: Query optimizer 8.0.1 (and 8.0)
Next
From: Sibtay Abbas
Date:
Subject: getting oid of function