Re: Clock sweep not caching enough B-Tree leaf pages? - Mailing list pgsql-hackers

From Merlin Moncure
Subject Re: Clock sweep not caching enough B-Tree leaf pages?
Date
Msg-id CAHyXU0z_R-XCdvVhH3PoBPeG3_jwuSCS81ji-UMcOvSOxAOLEg@mail.gmail.com
Whole thread Raw
In response to Re: Clock sweep not caching enough B-Tree leaf pages?  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Clock sweep not caching enough B-Tree leaf pages?
List pgsql-hackers
On Mon, Apr 20, 2015 at 9:56 AM, Robert Haas <robertmhaas@gmail.com> wrote:
> On Wed, Apr 15, 2015 at 5:00 PM, Martijn van Oosterhout
> <kleptog@svana.org> wrote:
>> I've been following this thread from the side with interest and got
>> twigged by the point about loss of information.  If you'd like better
>> information about relative ages, you can acheive this by raising the
>> cap on the usage count and dividing (or right-shifting) each sweep.
>
> Yeah, I thought about that, too.  It might be worth experimenting with.
>
>> This would allow you to remember much more about about the relative
>> worth of often used pages.  With a cap of 32 you'd have the same effect
>> as now where after 5 sweeps the buffer is evicted.  Mathematically the
>> count would converge to the number of times the block is used per
>> sweep.
>
> Hmm, interesting point.  It's possible that we'd still have problems
> with everything maxing out at 32 on some workloads, but at least it'd
> be a little harder to max out at 32 than at 5.

Do we have any reproducible test cases to evaluate these assumptions?I haven't looked at this stuff for a while, but my
mainissue with
 
the clock sweep was finding sweep heavy cases that did not also have
trouble with the buffer mapping locks (although the facts on the
ground my have changed since then).

merlin



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Clock sweep not caching enough B-Tree leaf pages?
Next
From: Heikki Linnakangas
Date:
Subject: Re: Sequence Access Method WIP