Fast-path locking improvements in PG18
summary
PG18 expands fast-path locking capacity (default 16 → 64 entries, tunable via max_locks_per_transaction) and implements a small set-associative small buffers design: hash to a bucket then do a linear scan in cache line, falling back to the main shared lock table on overflow. Code keeps fastpath protocol compatibility, reduces shared-lock-table CPU time dramatically in profiles, and yields order-of-magnitude throughput gains on workloads with many relations or partitions (examples include prepared-query joins across 10→100 partitions). Benchmarks and kernel-time flame charts show the change works.
AI-written summary · about
chapters (12)
- 0:00Introduction
- 1:03Why fast-path locking
- 6:51Debugging the bottleneck
- 11:10How fast-path locking works
- 15:29History of fast-path
- 18:03Performance improvements
- 19:53Designing the new buffer
- 24:10Set-associative cache
- 25:13Results and trade-offs
- 27:21Future improvements
- 29:29Acknowledgments
- 30:34Closing and resources
related talks
28mFast-path locking improvements in PG18
56mPerformance Improvements in PostgreSQL9 2
06mSomething Got Better For Partitioning in v18 Unless Reverted
30mOvercoming Performance Hurdles in Postgres Partitioned Tables
26mPartitioning your Postgres tables for 20x better performance
50mPerformance Improvements of Partitioning: Past and Future
29mPerformance Archaeology - 20 years of improvements
48mProblem in PostgreSQL SLRU - And how we are optimizing it