Re: LWLock granular partition lock memory layout - Mailing list pgsql-hackers

From Alexandre Felipe
Subject Re: LWLock granular partition lock memory layout
Date
Msg-id CAE8JnxPhhbyajhri9X6YRXX0WuR+tHt1D0AOea-Rk3j_i5YJKA@mail.gmail.com
Whole thread
In response to Re: LWLock granular partition lock memory layout  (Nathan Bossart <nathandbossart@gmail.com>)
Responses Re: LWLock granular partition lock memory layout
List pgsql-hackers


On Wed, Oct 7, 2026 at 7:56 PM Nathan Bossart <nathandbossart@gmail.com> wrote:
On Tue, Oct 06, 2026 at 08:44:53AM +0100, Alexandre Felipe wrote:
> I argue that having S partitions is better in several different ways.
>
> a. Concurrency of LW_EXCLUSIVE
> b. Reduced contention on LWLockWaitListLock
> c. Reduced CAS iterations in LWLockAtttemptLock
> d. Reduced waits (that implies wait list access and sleeping)
>
> I included a (pointless) benchmark result.

Your argument would be greatly improved by showing (with numbers) what
sorts of benefits this provides in realistic workloads.  I briefly looked
at benchmark.txt, but I couldn't quite tell what it was meant to show, and
you characterized it as pointless, anyway.

Hi Nathan,

The problem is that on a realistic workload on my lightweight laptop
I can't measure observe the LWLock effect at all. So the best I can do
is to remove the realistic part and test them on a tight loop.

I believe that if you are running on a multi-socket machine that would
be visible.



pgsql-hackers by date:

Previous
From: Masahiko Sawada
Date:
Subject: Re: Fix "unexpected logical decoding status change" error; from concurrent logical decoding activation
Next
From: Baji Shaik
Date:
Subject: Re: [PATCH] Unify duplicate-option handling across utility commands