On Mon, Dec 1, 2025 at 3:28 PM Andres Freund <[email protected]> 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
