LWLock granular partition lock memory layout

From: Alexandre Felipe <o(dot)alexandre(dot)felipe(at)gmail(dot)com>
To: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: LWLock granular partition lock memory layout
Date: 2026-10-06 07:44:53
Message-ID: CAE8JnxOGU4pT19z6JRVW9W0inS1cXt_pRPpCN0dAdTueo_GVkg@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

This time I am not changing LWLock semantics :)

Consider the a hash table partitioned in two different ways.

1. having S partitions, guarded by LWLocks on the same cache line.
2. having a single LWLock.

Which one will give better concurrency?
Which one will cost more to lock/unlock?

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.

And you can find a longer discussion in 0002 patch.

Attachment Content-Type Size
benchmark.txt text/plain 6.5 KB
v1-0002-introduce-LWLockAligned.patch application/octet-stream 8.4 KB
v1-0001-LWLock-struct-layout.patch application/octet-stream 11.9 KB

Browse pgsql-hackers by date

  From Date Subject
Previous Message Antonin Houska 2026-10-06 07:35:13 Re: REPACK (CONCURRENTLY) might keep dropped-column data