A deep dive into PostgreSQL's `commit_delay` and `commit_siblings` GUC parameters, explaining how they control group commit behavior by introducing a deliberate pause before WAL flushes to batch more transactions. The post clarifies the post-9.3 group commit mechanics, explains the correct tuning method using `pg_test_fsync` to measure flush cost, and describes how to interpret `pg_stat_wal` (or `pg_stat_io` in PG18) to confirm WAL sync is actually the bottleneck. The key insight: raise `commit_siblings` on fast storage (only batch under heavy concurrency), lower it on slow storage. For most workloads, defaults are correct, and `synchronous_commit` is a bigger lever for commit-cost savings.
4 Impressions