Re: [RFC, POC] Don't require a NBuffer sized PrivateRefCount array of local buffer pins

Andres Freund <andres(at)2ndquadrant(dot)com> writes:
> It's not unreasonable to argue that we just shouldn't optimize for
> several pins held by the same backend for the same and always touch the
> global count.

NAK. That would be a killer because of increased contention for buffer
headers. The code is full of places where a buffer's PrivateRefCount
jumps up and down a bit, for example when transferring a tuple into a
TupleTableSlot. (I said upthread that the number of pins is bounded by
the number of scan nodes, but actually it's probably some small multiple
of that --- eg a seqscan would hold its own pin on the current buffer,
and there'd be a slot or two holding the current tuple, each with its
own pin count.)

regards, tom lane