| 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.
| 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 |