@@ -1949,7 +1949,7 @@ include 'filename'
19491949 </indexterm>
19501950 <listitem>
19511951 <para>
1952- <varname>commit_delay</varname> adds a time delay, set in
1952+ <varname>commit_delay</varname> adds a time delay, measured in
19531953 microseconds, before a WAL flush is initiated. This can improve
19541954 group commit throughput by allowing a larger number of transactions
19551955 to commit via a single WAL flush, if system load is high enough
@@ -1959,17 +1959,20 @@ include 'filename'
19591959 flush. Because the delay is just wasted if no other transactions
19601960 become ready to commit, a delay is only performed if at least
19611961 <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>
19631968 In <productname>PostgreSQL</> releases prior to 9.3,
19641969 <varname>commit_delay</varname> behaved differently and was much
19651970 less effective: it affected only commits, rather than all WAL flushes,
19661971 and waited for the entire configured delay even if the WAL flush
19671972 was completed sooner. Beginning in <productname>PostgreSQL</> 9.3,
19681973 the first process that becomes ready to flush waits for the configured
19691974 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.
19731976 </para>
19741977 </listitem>
19751978 </varlistentry>
0 commit comments