Journey of developing a performance optimization feature in PGSQL
summary
A concrete feature is implemented that lets the WAL sender transmit unflushed WAL ahead of disk flushes, with the protocol carrying a flush pointer so the standby buffers records until the primary actually flushes. Iterative profiling uses perf+FlameGraph and pgbench custom workload (16–32 clients) to measure effects: WAL read I/O falls and TPS moves from 125 to 133 (~5% uplift) in high-latency tests. WAL receiver buffering and spill/flow-control remain to be profiled and hardened.
AI-written summary · about
chapters (10)
- 0:00Music & introduction
- 0:48Physical replication basics
- 3:54WAL flow from primary to standby
- 5:26WAL buffers, fsync, and tuning
- 8:41WAL sender loop and behavior
- 15:51Perf profiling and flamegraph insights
- 22:01Sending unflushed WAL
- 26:03Benchmark results & performance gains
- 28:26WAL receiver changes & alternative implementations
- 32:36Conclusion
related talks
31mPostgreSQL WAL and Commit Synchronization, Optimization Opportunities
53mVisualizing Postgres I O Performance for Development
24mPostgreSQL physical replication - internals, latest development and opportunities
27mAnalyzing Postgres performance problems using perf and eBPF
31mOptimizing Postgres for write heavy workloads ft. Checkpoint and WAL configs
56mPerformance Improvements in PostgreSQL9 2
35mUnderstanding and Optimizing commit sychronization for maximum performance
57mDurability in Postgres