commit_siblings

Definition PG 18 manual

Minimum number of concurrent open transactions to require before performing the commit_delay delay. A larger value makes it more probable that at least one other transaction will become ready to commit during the delay interval. The default is five transactions.

How it works

Sets the minimum number of concurrent open transactions required before performing "commit_delay". It can be changed at session scope, so different sessions may observe different behavior.

This is the concurrency gate for commit_delay, counted from other active transactions when a commit flush is needed. It is not a count of commits already waiting and has no useful effect while commit_delay is zero.

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

Operational considerations

Tuning it while commit_delay is zero, in which case the threshold has no effect.

Treating it as a count of commits already waiting rather than other active transactions.

Setting the gate too low and adding latency during ordinary moderate concurrency.

Applying a session-level experiment globally without comparing commit latency and WALSync behavior.

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_siblings 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.