Multi-threaded PostgreSQL?
summary
Proposal to move PostgreSQL from multiprocess to a single-address-space, one thread per connection model that immediately uses fewer TLBs and cheaper forks by replace fork with posix_create. Plan requires annotating ~2–4k global variables, a clang plugin to list unannotated globals, rewriting signal handling and FD subsystems, adding an extension control flag for thread safety, and a babysitter postmaster process for crash isolation. Benefits: easier shared caches, dynamic resizing, built-in connection pooling; risks: long-lived memory leaks, extension porting, and a transition over one to three releases.
AI-written summary · about
chapters (7)
- 0:00Introduction
- 1:30Multiprocess vs multithreaded
- 10:21Objections to multithreading
- 28:09Previous attempts
- 31:02Implementation plan
- 46:21Challenges and next steps
- 49:53Q&A and conclusion
related talks
46mMulti-threaded PostgreSQL?
46mInvestigating Multithreaded PostgreSQL
30mPostgreSQL and Linux Kernel interactions
26mLinux and PostgreSQL in the Multiverse of Connections
26mRethinking PostgreSQL Performance in the Age of Monster Hardware
52mNUMA vs PostgreSQL
51mScaling Postgres to the next level at OpenAI
56mPerformance Improvements in PostgreSQL9 2