Re: LWLock granular partition lock memory layout

From: Alexandre Felipe <o(dot)alexandre(dot)felipe(at)gmail(dot)com>
To: Nathan Bossart <nathandbossart(at)gmail(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: LWLock granular partition lock memory layout
Date: 2026-10-07 19:22:38
Message-ID: CAE8JnxPhhbyajhri9X6YRXX0WuR+tHt1D0AOea-Rk3j_i5YJKA@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Oct 7, 2026 at 7:56 PM Nathan Bossart <nathandbossart(at)gmail(dot)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.

In response to

Browse pgsql-hackers by date

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