Proper PostgreSQL Parameters to Prevent Poor Performance
summary
PostgreSQL tuning focuses on a handful of settings that actually change behavior: set shared_buffers to about 25–40% of RAM on a dedicated box to cut reads, keep work_mem per query modest (the presenter recommends start with 4MB) because exceeding it creates temp files and caused a real system to go from fast to “everything is on fire” under hundreds of queries/sec, limit max_connections to roughly 10–20 connections per core, and set random_page_cost = 1 for SSDs; also monitor effective_cache_size (~50% RAM), vacuum to avoid wraparound, and use connection pooling.
AI-written summary · about
chapters (9)
- 0:00PostgreSQL memory architecture
- 5:38PostgreSQL performance parameters
- 12:50Tuning shared buffers
- 14:42Max connections trade-offs
- 27:33Vacuum and maintenance
- 30:51Random page cost and indexes
- 33:06Connection pooling and caching
- 35:12Performance optimization tips
- 37:25Q&A: Database bottlenecks
related talks
34mTuning PostgreSQL to work even better
43mPostgres Performance: From Slow to Pro
33mTuning PostgreSQL to work even better
52mPostgreSQL Configuration for Humans
57mPostgreSQL When It's Not Your Job
25mScaling PostgreSQL Beyond Query Optimization
48mPractical Memory Tuning for PostgreSQL
27mPostgres Performance in 15 Minutes