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
suspectit 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
thenext 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
tostart with a more complex multi-lock/multi-freelist implementation before we knew we needed one.
--
Jim C. Nasby, Data Architect jim@nasby.net
512.569.9461 (cell) http://jim.nasby.net
