{"Entry":{"collection":"guc","key":"commit_delay","name":"commit_delay","aliases":[],"metadata":{"baseline":true,"boot_human":"Not specified","boot_val":null,"category":"Write-Ahead Log / Settings","category_zh":"","changed_in":["9.3"],"changes":[{"documentation_changed":true,"fields":{},"from":"7.4","status":"changed","to":"8.0"},{"documentation_changed":true,"fields":{},"from":"9.0","status":"changed","to":"9.1"},{"documentation_changed":true,"fields":{"context":{"from":"user","to":"superuser"}},"from":"9.2","status":"changed","to":"9.3"},{"documentation_changed":true,"fields":{},"from":"11","status":"changed","to":"12"},{"documentation_changed":true,"fields":{},"from":"14","status":"changed","to":"15"}],"content_hash":"d347074b9a7b4b839e56acab73e469e80ac96abbe156b153988d53ec75f7f0ec","context":"","default_changed_in":[],"default_history":[{"from":"9.0","to":"19","value":"0"}],"derived_content_hash":"a9a8802b230f53be809a6b9345425c73561e68199d9f53682b8fac85671b5a79","editorial":{"advice":{"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."},"mechanism":["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."],"pitfalls":["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."],"references":[{"title":"PostgreSQL 19 Beta 4: commit_delay","url":"https://www.postgresql.org/docs/19/runtime-config-wal.html#GUC-COMMIT-DELAY"},{"title":"PostgreSQL 19 release notes","url":"https://www.postgresql.org/docs/19/release-19.html"}],"related":["commit_siblings","synchronous_commit","wal_writer_delay","wal_sync_method","fsync","full_page_writes"],"summary":"commit_delay — Sets the delay in microseconds between transaction commit and flushing WAL to disk. Observed in PG9.0–19 Beta 4; its last measured boot default is 0 in PG19 Beta 4, with superuser context. This is a beta-snapshot fact and can change before PostgreSQL 19 GA."},"enumvals":[],"first_version":"7.4","group":"Write-Ahead Log","group_slug":"wal","imported_at":"2026-09-27T17:57:30.958922+08:00","intro_commit":{},"key":"commit_delay","last_version":"20","max_val":"","min_val":"","name":"commit_delay","position":64,"present_in":["7.4","8.0","8.1","8.2","8.3","8.4","9.0","9.1","9.2","9.3","9.4","9.5","9.6","10","11","12","13","14","15","16","17","18","19","20"],"repair_provenance":{"original_source_revision":"english-manuals:eac2ac29747c2839645105fc24fc53de82ab0a9d6591ec2f01e9da2f7aac8ba6","receipt_sha256":"c52a0a403da7439fd92766d894f9114536c1f70c462de84cceb27ed1ebc23196","repair":"wiki-repair-20261023"},"short_desc":"Setting commit_delay adds a time delay before a WAL flush is initiated.","short_desc_zh":"","source_rev":"wiki-repair-20261023:c56bcd22b2dbaa998936ea9818475e41f13a2a7563d0243277be6f01819ae744","unit":"","vartype":"integer"}},"Definition":{"Collection":"guc","Key":"commit_delay","SourceDatabase":"center","Version":"18","SourceTable":"guc","SourceKey":"commit_delay","SourceRevision":"wiki-repair-20261023:c56bcd22b2dbaa998936ea9818475e41f13a2a7563d0243277be6f01819ae744","Facts":{"boot_val":"0","category":"Write-Ahead Log / Settings","context":"superuser","description":"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.","description_zh":"设置 commit_delay 会在发起 WAL 刷盘之前添加时间延迟。如果系统负载足够高，使得在给定时间间隔内有更多事务准备提交，这可以通过允许更多事务通过一次 WAL 刷盘来提高组提交吞吐量。不过，每次 WAL 刷盘的延迟也会因此增加，最多增加 commit_delay。如果没有其他事务准备提交，等待就没有意义，因此仅当即将发起刷盘时至少还有 commit_siblings 个其他活动事务，才会等待。此外，如果禁用了 fsync，也不会等待。如果未指定单位，则将其视为微秒。默认 commit_delay 为零（无延迟）。只有超级用户和具有适当 SET 权限的用户才能更改此设置。 在 PostgreSQL 的 9.3 发布之前，commit_delay 的行为不同并且效果更差：它只影响提交，而不是所有 WAL 刷写，并且即使 WAL 刷盘更早完成，也会等待整个配置的延迟时间。从 PostgreSQL 9.3 开始，第一个准备好刷写的进程会等待配置的间隔，而后续的进程只等到领先者完成刷写操作。","description_zh_html":"\u003cp\u003e\n        设置 \u003ccode class=\"varname\"\u003ecommit_delay\u003c/code\u003e 会在发起 WAL 刷盘之前添加时间延迟。如果系统负载足够高，使得在给定时间间隔内有更多事务准备提交，这可以通过允许更多事务通过一次 WAL 刷盘来提高组提交吞吐量。不过，每次 WAL 刷盘的延迟也会因此增加，最多增加 \u003ccode class=\"varname\"\u003ecommit_delay\u003c/code\u003e。如果没有其他事务准备提交，等待就没有意义，因此仅当即将发起刷盘时至少还有\n        \u003ccode class=\"varname\"\u003ecommit_siblings\u003c/code\u003e 个其他活动事务，才会等待。此外，如果禁用了 \u003ccode class=\"varname\"\u003efsync\u003c/code\u003e，也不会等待。如果未指定单位，则将其视为微秒。默认 \u003ccode class=\"varname\"\u003ecommit_delay\u003c/code\u003e 为零（无延迟）。只有超级用户和具有适当 \u003ccode class=\"literal\"\u003eSET\u003c/code\u003e 权限的用户才能更改此设置。\n       \u003c/p\u003e\u003cp\u003e\n        在 \u003cspan class=\"productname\"\u003ePostgreSQL\u003c/span\u003e 的 9.3 发布之前，\u003ccode class=\"varname\"\u003ecommit_delay\u003c/code\u003e 的行为不同并且效果更差：它只影响提交，而不是所有 WAL 刷写，并且即使 WAL 刷盘更早完成，也会等待整个配置的延迟时间。从 \u003cspan class=\"productname\"\u003ePostgreSQL\u003c/span\u003e 9.3 开始，第一个准备好刷写的进程会等待配置的间隔，而后续的进程只等到领先者完成刷写操作。\n       \u003c/p\u003e","doc":{"anchor":"GUC-COMMIT-DELAY","file":"runtime-config-wal.html","lang":"en","sha256":"d2646404a06e8f7ac655204b4f28c049ae8f3fd4f2272db080fcefa2c4af0763","slug":"18"},"documented":true,"enumvals":null,"extra_desc":null,"lang":"en","max_val":"100000","metadata_version":"18","min_val":"0","name":"commit_delay","short_desc":"Sets the delay in microseconds between transaction commit and flushing WAL to disk.","source":"pg-settings-source-snapshot","translation_provenance":{"inputs":[{"kind":"current-pgdoc-translation","path":"/Users/vonng/pgsty/pgdoc/zh/18/html/runtime-config-wal.html","sha256":"94cdacb1171b4c528492ca0aec6aafa48a2c758276225fe0dbfe5b12452d4930"}],"kind":"same-version-pgdoc","locale":"zh-Hans","source_revision":"b1b500221dbe5437cfca004d6b04d3f6e422765d","version":"18"},"unit":null,"vartype":"integer","zh_from":"same-version-pgdoc"},"ManualEvidence":{"doc":{"anchor":"GUC-COMMIT-DELAY","file":"runtime-config-wal.html","lang":"en","sha256":"d2646404a06e8f7ac655204b4f28c049ae8f3fd4f2272db080fcefa2c4af0763","slug":"18"}},"MeasuredEvidence":{"metadata_version":"18"}},"Text":{"Collection":"guc","Key":"commit_delay","SourceDatabase":"center","Version":"18","Locale":"en","Title":"commit_delay","Summary":"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.","BodyHTML":"\u003cp\u003eSetting 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.\u003c/p\u003e","SourceRevision":"wiki-repair-20261023:c56bcd22b2dbaa998936ea9818475e41f13a2a7563d0243277be6f01819ae744","ContentHash":"20998cb773ef57c8d7fd6d9650b37d317319d49a932f4dad576a5bd9bd6cf6da","Payload":{"description":"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."}},"RequestedLocale":"en","Fallback":false,"Versions":["10","11","12","13","14","15","16","17","18","19","20","7.4","8.0","8.1","8.2","8.3","8.4","9.0","9.1","9.2","9.3","9.4","9.5","9.6"],"Locales":["en","zh-Hans"],"Signatures":null,"Spellings":null,"SQLState":null,"Evidence":null}