Practical Memory Tuning for PostgreSQL
summary
Poor memory settings cause dramatic slowdowns: a misconfigured server shows an 11x reduction in throughput when buffers and swap are wrong, and the OOM killer targets recent backends and risks whole-cluster restarts. Hugepages matter at scale — a 160GB working set benchmark collapses without them at high client counts. Work_mem and hash_mem multiplier tuning speeds joins (multiplier=8 with work_mem=2 yields ~75% faster runs) while Postgres 17 brings a 5x reduction in vacuum memory and can use >1GB, avoiding many extra index scans. Beware prepared-statement bloat — 10 million prepared statements used 85GB and crashed the server.
AI-written summary · about
chapters (14)
- 0:00Introduction and importance
- 1:52Memory, swapping, and OOM
- 3:17The role of swap memory
- 6:28Memory structure in PostgreSQL
- 9:01Understanding working sets
- 12:06Optimizing shared buffers
- 18:10Huge pages configuration
- 21:58Cluster and session parameters
- 24:00Work memory and operations
- 29:14Prepared statements bloat
- 30:55Maintenance work memory
- 32:56Vacuum performance in 17+
- 39:19Advanced vacuum configurations
- 42:17Questions and answers
related talks
45mProper PostgreSQL Parameters to Prevent Poor Performance
43mPostgres Performance: From Slow to Pro
33mTuning PostgreSQL to work even better
34mTuning PostgreSQL to work even better
57mPostgreSQL When It's Not Your Job
25mScaling PostgreSQL Beyond Query Optimization
55mScaling PostgreSQL: Horizontal vs. Vertical
18mTuning Parameters in Postgres vs. Tuning Your Queries