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.
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_1 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_1 && git checkout t254081_1Patchset v1 (message #1) is on t254081_1
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.