On Mon, Dec 20, 2004 at 11:20:46PM -0500, Tom Lane wrote:
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > Tom Lane wrote:
> >> Exactly. But 1% would be uselessly small with this definition. Offhand
> >> I'd think something like 50% might be a starting point; maybe even more.
> >> What that says is that a page isn't a candidate to be written out by the
> >> bgwriter until it's fallen halfway down the LRU list.
>
> > So we are not scanning by buffer address but using the LRU list? Are we
> > sure they are mostly dirty?
>
> No. The entire point is to keep the LRU end of the list mostly clean.
>
> Now that you mention it, it might be interesting to try the approach of
> doing a clock scan on the buffer array and ignoring the ARC lists
> entirely. That would be a fundamentally different way of envisioning
> what the bgwriter is supposed to do, though. I think the main reason
> Jan didn't try that was he wanted to be sure the LRU page was usually
> clean so that backends would seldom end up doing writes for themselves
> when they needed to get a free buffer.
>
> Maybe we need a hybrid approach: clean a few percent of the LRU end of
> the ARC list in order to keep backends from blocking on writes, plus run
> a clock scan to keep checkpoints from having to do much. But that's way
> beyond what we have time for in the 8.0 cycle.
>
> regards, tom lane
>
I have not had a chance to investigate, but there is a modification of
the ARC cache strategy called CAR that replaces the LRU linked lists
with the clock approximation to the LRU lists. This algorithm is virtually
identical to the current ARC but reduces the contention at the MRU end
of the lists. This may dovetail nicely into your idea of a "clock" bgwriter
functionality as well as help with the cache-line performance problem.
Yours,
Ken Marshall