Re: Buffer locking is special (hints, checksums, AIO writes)

On Mon, Dec 1, 2025 at 3:28 PM Andres Freund <andres(at)anarazel(dot)de> wrote:
>
> > I noticed that the BUF_STATE_GET_REFCOUNT and BUF_STATE_GET_USAGECOUNT
> > macros cast the return value to a uint32. We won't use the extra bits
> > but we did bother to keep the macro result sized to the field width
> > before so keeping it uint32 is probably more confusing now that state
> > is 64 bit.
>
> I can't really follow - why would we want to return a 64bit value if none of
> the values ever can get anywhere near that big?

Well, usagecount could never have reached anything close to a uint32
either, so I thought that this cast was meant to match the datatype. I
found it rather confusing otherwise.

> > 0007
> > needs a commit message. overall seems fine though.
>
> This is what I've since written:
>
> bufmgr: Add one-entry cache for private refcount
>
> The private refcount entry for a buffer is often looked up repeatedly for the
> same buffer, e.g. to pin and then unpin a buffer. Benchmarking shows that it's
> worthwhile to have a one-entry cache for that case. With that cache in place,
> it's worth splitting GetPrivateRefCountEntry() into a small inline
> portion (for the cache hit case) and an out-of-line helper for the rest.
>
> This is helpful for some workloads today, but becomes more important in an
> upcoming patch that will utilize the private refcount infrastructure to also
> store whether the buffer is currently locked, as that increases the rate of
> lookups substantially.

Sounds good based on what I recall of the patch.

- Melanie