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

On 4/16/14, 10:28 AM, Robert Haas wrote:
> Also, I think the scalability problems around buffer eviction are
> eminently solvable, and in particular I'm hopeful that Amit is going
> to succeed in solving them. Suppose we have a background process
> (whether the background writer or some other) that runs the clock
> sweep, identifies good candidates for eviction, and pushes them on a
> set of, say, 16 free-lists protected by spinlocks. (The optimal
> number of free-lists probably depends on the size of shared_buffers.)

How *certain* are we that a single freelist lock (that actually ONLY protects the freelist) would be that big a deal? I suspect it wouldn't be much of an issue at all:

- Right now (IIRC) it's tied into the clock as well, so immediate fail on scaling...
- The clock is WAY more expensive than grabbing one buffer off the free list. Last I looked it was so bad that even if the next buffer the clock hit was free it was still worse than hitting the free list.

I strongly suspect that a single freelist lock (that didn't protect anything else) would be fine. I think it'd be folly to start with a more complex multi-lock/multi-freelist implementation before we knew we needed one.
--
Jim C. Nasby, Data Architect jim(at)nasby(dot)net
512.569.9461 (cell) http://jim.nasby.net