@@ -1949,7 +1949,7 @@ include 'filename'
1949
1949
</indexterm>
1950
1950
<listitem>
1951
1951
<para>
1952
- <varname>commit_delay</varname> adds a time delay, set in
1952
+ <varname>commit_delay</varname> adds a time delay, measured in
1953
1953
microseconds, before a WAL flush is initiated. This can improve
1954
1954
group commit throughput by allowing a larger number of transactions
1955
1955
to commit via a single WAL flush, if system load is high enough
@@ -1959,17 +1959,20 @@ include 'filename'
1959
1959
flush. Because the delay is just wasted if no other transactions
1960
1960
become ready to commit, a delay is only performed if at least
1961
1961
<varname>commit_siblings</varname> other transactions are active
1962
- immediately before a flush would otherwise have been initiated.
1962
+ when a flush is about to be initiated. Also, no delays are
1963
+ performed if <varname>fsync</varname> is disabled.
1964
+ The default <varname>commit_delay</> is zero (no delay).
1965
+ Only superusers can change this setting.
1966
+ </para>
1967
+ <para>
1963
1968
In <productname>PostgreSQL</> releases prior to 9.3,
1964
1969
<varname>commit_delay</varname> behaved differently and was much
1965
1970
less effective: it affected only commits, rather than all WAL flushes,
1966
1971
and waited for the entire configured delay even if the WAL flush
1967
1972
was completed sooner. Beginning in <productname>PostgreSQL</> 9.3,
1968
1973
the first process that becomes ready to flush waits for the configured
1969
1974
interval, while subsequent processes wait only until the leader
1970
- completes the flush. The default <varname>commit_delay</> is zero
1971
- (no delay). No delays are performed unless <varname>fsync</varname>
1972
- is enabled.
1975
+ completes the flush operation.
1973
1976
</para>
1974
1977
</listitem>
1975
1978
</varlistentry>
0 commit comments