commit_delay

Definition PG 18 manual

Setting commit_delay adds a time delay before a WAL flush is initiated. This can improve group commit throughput by allowing a larger number of transactions to commit via a single WAL flush, if system load is high enough that additional transactions become ready to commit within the given interval. However, it also increases latency by up to the commit_delay for each WAL flush. Because the delay is just wasted if no other transactions become ready to commit, a delay is only performed if at least commit_siblings other transactions are active when a flush is about to be initiated. Also, no delays are performed if fsync is disabled. If this value is specified without units, it is taken as microseconds. The default commit_delay is zero (no delay). Only superusers and users with the appropriate SET privilege can change this setting.

In PostgreSQL releases prior to 9.3, commit_delay behaved differently and was much less effective: it affected only commits, rather than all WAL flushes, and waited for the entire configured delay even if the WAL flush was completed sooner. Beginning in PostgreSQL 9.3, the first process that becomes ready to flush waits for the configured interval, while subsequent processes wait only until the leader completes the flush operation.

How it works

Sets the delay in microseconds between transaction commit and flushing WAL to disk. A superuser or a role granted SET privilege can change it for the relevant session or configuration scope.

A backend that is about to flush commit WAL may wait this many microseconds so concurrent commits can join the same durable flush. The delay is considered only when at least commit_siblings other transactions are active, trading individual latency for possible group-commit efficiency.

Monitor and change commit_delay together with commit_siblings, synchronous_commit, wal_writer_delay. Validate on the relevant server role and real workload, then use its superuser context to choose session change, reload, or restart; a historical boot default is not the current effective value.

Operational considerations

Setting a delay while commit_siblings prevents it from being reached under the real concurrency level.

Reading the value as milliseconds even though the unit is microseconds.

Increasing average group-commit throughput while violating p95 or p99 commit-latency objectives.

Expecting a delay when the commit path does not need to flush WAL.

Changing commit_delay without measuring it together with commit_siblings and WALSync waits.

Workload guidance

OLAP: Bulk jobs should usually reduce commit frequency with sensible transaction batches; do not use group-commit delay to compensate for row-at-a-time ETL commits.

OLTP: Benchmark commit_delay only under high commit concurrency with material WALSync waits and an acceptable p95/p99 latency budget. Tune commit_delay and commit_siblings as a pair and retain a zero-delay baseline.

SMALL: Low concurrency provides little opportunity, so commit_delay=0 is simplest. Even a microsecond value needs end-to-end latency evidence.