LWLock granular partition lock memory layout
Hackorum builds and tests every patch posted to the lists, not only commitfest submissions. This is Hackorum's own CI rather than the PostgreSQL project's, and it is still under testing - please report anything that looks wrong.
You can run a PostgreSQL built from this patch straight from Docker, with no checkout and no build:
docker run --rm -p 5432:5432 ghcr.io/hackorum-dev/postgres-patch:t254081psql -h localhost -U postgresBuilt from patchset v2 (message #2), October 22, 2026 at 04:22 AM.
Every patchset is also pushed to a branch of our PostgreSQL fork, so you can check out the same tree CI built. Without a PostgreSQL checkout:
git clone --branch t254081_2 https://github.com/hackorum-dev/postgres.gitIn a checkout you already have, add the fork once:
git remote add hackorum https://github.com/hackorum-dev/postgres.gitthen, for this patchset and every later one:
git fetch hackorum t254081_2 && git checkout t254081_2Patchset v2 (message #2) is on t254081_2
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.
Attachments:
t254081_1benchmark.txttext/plain; charset=US-ASCII; name=benchmark.txtDownload
v1-0002-introduce-LWLockAligned.patchapplication/octet-stream; name=v1-0002-introduce-LWLockAligned.patchDownload+37-12
v1-0001-LWLock-struct-layout.patchapplication/octet-stream; name=v1-0001-LWLock-struct-layout.patchDownload+63-53
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.
--
nathan
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.
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)
In theory this has benefits with no compromises.
In practice, it is more impactful than I initially expected.
I thought it would be noticeable only in large scale systems, but even on my
lightweight laptop with 8 cores the results are measurable.
With 128 partitions
clients base patched
1 26371.6 26149.2
8 35659.7 44958.5 +26.1%
Regards,
Alexandre