Fast-path locking improvements in PG18
summary
Postgres 18 expands fast‑path locking from a fixed 16‑oid per‑backend buffer to any number of 16‑way set‑associative chunks (size tied to max_locks_per_transaction, default 64), cutting shared lock table contention and showing roughly 3× throughput for simple queries and 5× for prepared statements in the presented benchmarks. Implementation shifts cost into memory allocation (glibc malloc) and reveals other limits (join planning, buffer pinning, NUMA), so it works and speeds partitioned/index‑heavy workloads but uncovers the next bottlenecks.
AI-written summary · about
chapters (9)
- 0:00Introduction and context
- 2:39Analyzing the performance issue
- 6:15Pinpointing the bottleneck
- 9:33Historical fast-path locking
- 13:10Designing the new cache
- 17:44Performance results and trade-offs
- 19:23Remaining challenges
- 23:19Future work and conclusions
- 25:35Wrap up and final remarks
related talks
32mFast-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
42mPushing Postgres Forward: From Open Source Contributions to Intelligent T
52mNUMA vs PostgreSQL
52mBoosting Typical Query Patterns: PostgreSQL 18's Performance Enhancements
29mPerformance Archaeology - 20 years of improvements