Re: Thinking about breaking up the BufMgrLock

>Tom Lane
> "Simon Riggs" <simon(at)2ndquadrant(dot)com> writes:
> > After much thought, I believe the best way is to implement
> bufferpools
> > (BPs). That is, we don't just have one bufferhash and one
> LRU, we have
> > many pairs. We then work out some mapping by which a block
> can be known
> > to be in a particular BP, then acquire the lock for that BP.
>
> I think this is basically wrongheaded, because it achieves
> its reduction
> in contention by a one-for-one sacrifice of cache allocation
> efficiency;
> that is, any individual page is now fighting for survival in
> a pool only
> 1/Nth as large as before. We're going to lose more in I/O than we can
> hope to save at the processor level.

Well, as you might expect, I disagree. I also expected that reaction:
ISTM when all good ideas are used up - as you carefully explained was
the case, it must be a more offbeat idea that is the next good one (to
paraphrase Sherlock Holmes).

I do agree that the goal is to reduce contention without increasing I/O.

With BPs: Yes, an individual block is fighting for survival in a smaller
pool, but the number of blocks that might want to go in the pool is also
reduced by the same ratio. With a small shared_buffers, shorter lists
might be a problem, but sizing it large enough would take away some
issues also. I think a straightforward list balancing algorithm would
reduce any imbalance across lists.

BPs would not giving much benefit on a single CPU - my goal here is to
increase SMP performance.

Overall, performance results must be the final arbiter in what is best.

Best Regards, Simon Riggs