Re: WIP: 2nd-generation buffer ring patch

Heikki Linnakangas <heikki(at)enterprisedb(dot)com> writes:
> Also there's no attempt to not inflate usage_count, which means that
> synchronized scans will spoil the buffer cache as if we didn't have the
> buffer ring patch.

As I said, these patches are hardly independent.

> If there's no easy solution, I think we could live
> with that, but Greg's suggestion of bumping the usage_count in PinBuffer
> instead of UnpinBuffer sounds like a nice solution to me.

After thinking about it more, I'm a bit hesitant to do that because it
will change the interaction with the clock sweep for buffers that stay
pinned for awhile. I had suggested making the clock sweep not decrement
usage_count of a pinned buffer, but I think that would change the
fairness of the algorithm. OTOH it may not matter that much if we just
move the usage_count increment and leave the clock sweep alone. Do we
have any decent way of measuring the effectiveness of the clock-sweep
allocation algorithm?

I also thought about having ReadBuffer decrement the usage count when it
has a nondefault strategy and finds the buffer already in cache; this
would then cancel out the later unconditional increment in UnpinBuffer.
But that makes twice as many cycles spent holding the buffer spinlock.

Either one of these methods would require PinBuffer to be aware of the
strategy argument, which it is not at present. OTOH with the first way
we could get rid of the "normalAccess" argument to UnpinBuffer, so
there's some net conservation of cruft I guess. I think I had
originally given this task to UnpinBuffer on the theory that we'd have
better information at unpin time than pin time about what the buffer
state had been and thus be able to make smarter decisions about whether
to bump the access count or not. But at the moment it doesn't seem that
we really need any such info; AFAICS all the callers of PinBuffer know
what they want to happen.

regards, tom lane