Parameter · Write-Ahead Log / Settings

commit_delay

Sets the delay in microseconds between transaction commit and flushing WAL to disk.

Default: 0
Type: integer
Range: 0 … 100000
Applies: Session (superuser)

In plain words

Each commit must wait for a WAL flush, and flushes are slow. If many sessions commit at nearly the same time, one flush can cover all of them ("group commit"). commit_delay makes the first session that is ready to flush wait a moment so more commits can join.

It only helps on very busy systems with slow flushes; otherwise it just adds latency. Default 0 (off).

For DBAs and operators

Since PostgreSQL 9.3: when a backend becomes the leader for a WAL flush, it sleeps commit_delay µs before flushing, but only if at least commit_siblings other transactions are active and fsync is on. Backends arriving meanwhile wait for that flush instead of starting their own. Group commit already happens naturally (commits queue behind an in-progress flush); the delay just makes groups larger.

Tuning

Start with about half the single-flush time reported by pg_test_fsync (e.g. 500–1000 µs for a disk with 1–2 ms fsyncs). On fast NVMe with power-loss protection, gains are usually negligible.
Measure throughput with pgbench at your real concurrency; watch pg_stat_io WAL fsyncs (PG18) dropping per commit.
It is a superuser-only setting (user-settable via GRANT SET).

How to change it

A superuser (or a role granted SET) can change it per session with SET.

See it in context

Write-ahead log (WAL) WAL writer

Related parameters

commit_siblings synchronous_commit wal_sync_method fsync

All Write-Ahead Log parameters