public inbox for [email protected]
help / color / mirror / Atom feedFrom: Melanie Plageman <[email protected]>
To: Andres Freund <[email protected]>
Cc: Matthias van de Meent <[email protected]>
Cc: [email protected]
Cc: Thomas Munro <[email protected]>
Cc: Heikki Linnakangas <[email protected]>
Cc: Noah Misch <[email protected]>
Cc: Robert Haas <[email protected]>
Cc: Michael Paquier <[email protected]>
Subject: Re: Buffer locking is special (hints, checksums, AIO writes)
Date: Mon, 1 Dec 2025 15:41:07 -0500
Message-ID: <CAAKRu_bFyKsGcoCznoT78sF9EYbVeWsXPfhdJnGLsHzoA01Sww@mail.gmail.com> (raw)
In-Reply-To: <js7t2fs6it2aljskgqzpqwj4uqc5geb4ztlcojsyh6bpzgaqew@nixo44lyx5vn>
References: <fvfmkr5kk4nyex56ejgxj3uzi63isfxovp2biecb4bspbjrze7@az2pljabhnff>
<yivb2evcrj7fna5ymuunw3g5u5xxttwjbjxaa4ofkfkviystjv@4dfylftqxyxh>
<6kmid26do57ykqfpvq6iieniy4djsymhrypkjccazq5g4bbe6a@2y6owwv7qpex>
<CAEze2WgGe8vjj3jiWqUugWuwLJ9cLryaGrnASjm-yJ=tEALX2A@mail.gmail.com>
<pmto7djq64mei53p7r5smfync2waittilhbuzc7j7lpflf2b3y@laz7r76y5pux>
<CAEze2WjeK9CY003S4dmCugv_H4tz9AaXgnqW+wTc=BaPDg+2xg@mail.gmail.com>
<3je3ahgf7rrmmurxo6hnlhg5d3ffwfrtjwjxd6jm5srlv5iebp@vxqk5qtgmowr>
<3w7v3w6a57jnssokap4k7thoekig72flnyhd4wp3yftzdd7lm7@f6lpcfen6hr7>
<6rgb2nvhyvnszz4ul3wfzlf5rheb2kkwrglthnna7qhe24onwr@vw27225tkyar>
<CAAKRu_Y6H=_Jx=F77v_ArXza5wwDn-J1FiHr3_+F7aBBwy0TsQ@mail.gmail.com>
<js7t2fs6it2aljskgqzpqwj4uqc5geb4ztlcojsyh6bpzgaqew@nixo44lyx5vn>
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
view thread (57+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected]
Subject: Re: Buffer locking is special (hints, checksums, AIO writes)
In-Reply-To: <CAAKRu_bFyKsGcoCznoT78sF9EYbVeWsXPfhdJnGLsHzoA01Sww@mail.gmail.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox