Rethinking PostgreSQL Performance in the Age of Monster Hardware
summary
Postgres is largely not NUMA-aware, so on modern multi-socket servers shared_buffers can sit on a different NUMA node than worker processes, increasing latency; competitors (Oracle, SQL Server, DB2) have had NUMA solutions for years. Use numactl or systemd CPU affinity, limit connections, reduce shared_buffers, or run a single-socket host (up to 384 threads on Gen‑5 AMD) as practical workarounds. Postgres 18 adds pg_buffer_cache numa observability (libnuma required). Persistent IO latency remains the common real-world bottleneck.
AI-written summary · about
chapters (10)
- 0:00Introduction
- 0:54NUMA architecture explained
- 5:37Sub-NUMA complexity
- 8:04Other databases' NUMA solutions
- 9:57PostgreSQL NUMA workarounds
- 13:57Is NUMA worth solving?
- 16:53PostgreSQL process model limits
- 19:50Threaded architecture debate
- 21:55Bottlenecks beyond CPU
- 24:30Optimization priorities
related talks
52mNUMA vs PostgreSQL
26mLinux and PostgreSQL in the Multiverse of Connections
36mBest Practices in PostgreSQL Tuning: Navigating Key Performance Bottlenecks in the Cloud
45mProper PostgreSQL Parameters to Prevent Poor Performance
43mPostgres Performance: From Slow to Pro
17mThe Evolution of Postgres Performance
48mPractical Memory Tuning for PostgreSQL
55mScaling PostgreSQL: Horizontal vs. Vertical