Re: Clock sweep not caching enough B-Tree leaf pages?

On Wed, Apr 16, 2014 at 2:18 AM, Andres Freund <andres@2ndquadrant.com> wrote:
> *I* don't think any scheme that involves measuring the time around
> buffer pins is going to be acceptable. It's better than I say that now
> rather than when you've invested significant time into the approach, no?

Well, I do think that it will be possible to make something like that
work. LRU-K/LRU-2 involves remembering the last two access times (not
the last one). Researchers considered preeminent authorities on
caching algorithms thought that was a good idea in 1993. There are
plenty of other examples of similar schemes too.

>> No, it shouldn't, because there is a notion of buffers getting a fair
>> chance to prove themselves.
>
> If you have a workload with > (BM_MAX_USAGE_COUNT + 1) clock
> cycles/second, how does *any* buffer has a chance to prove itself?

There could be lots of ways. I thought about representing that more
directly. I don't think that it's useful to have a large number of
revolutions in search of a victim under any circumstances.
Fundamentally, you're asking "what if any scheme here leans too
heavily towards frequency?". That could certainly be a problem, as
I've said, and we could think about adaptation over heuristics, as
I've said, but it is very obviously a big problem that clock sweep
doesn't really care about frequency one bit right now.

Why should I be the one with all the answers? Aren't you interested in
the significance of the patch, and the test case?

-- 
Peter Geoghegan