Re: [PATCH] bufmgr: tighten LWLock:BufferMapping on InvalidateBuffer

On Mon, Aug 24, 2026 at 1:25 PM Andres Freund <andres(at)anarazel(dot)de> wrote:

> On 2026-08-24 09:16:28 +0100, Alexandre Felipe wrote:
> > I also studied the current LWLock the implementation and there is room to
> > make the no-contention path faster. Is that something worth doing,
> > or is it pointless?
>
> Hard to say without knowing what you're actually going to propose. Of couse
> making the uncontended path faster is attractive, but correctness /
> complexity
> / contended performance all are also not uninmportant.
>

Here I include the experiments. Maybe you don't want to use this
implementation
but it might give you some hints to write a faster version that you like.

There are no algorithmic changes. The changes are about

0002 having two distinct paths for LW_EXCLUSIVE and LW_SHARED,
the rest is diminishing returns. And also added LWLockReleaseLast,
added wrappers as inline functions in lwlock.h that compiles the
current code base replacing the calls
LWLockAcquire(lock, LW_EXCLUSIVE | LW_SHARED) by the
LWLockAcquire(Exclusive|Shared)(lock)

0003 reading the mode from the LWLock state and saving space and time
storing it in the held lwlocks array.
0004 well, bring LWLock(Acquire/Release)X external functions that take
mode as a parameter (a baseline).
0005 Inlined LWLockAttemptLock and folded the loop, placing a single
LWLockAttemptLock at the top of the loop followed by the common logic
(previously at the end bottom of the function), then enqueue and continue
or wait.

Regards,
Alexandre