|
1 | 1 | <!--
|
2 |
| -$Header: /cvsroot/pgsql/doc/src/sgml/runtime.sgml,v 1.62 2001/05/0402:54:33 momjian Exp $ |
| 2 | +$Header: /cvsroot/pgsql/doc/src/sgml/runtime.sgml,v 1.63 2001/05/0423:11:37 tgl Exp $ |
3 | 3 | -->
|
4 | 4 |
|
5 | 5 | <Chapter Id="runtime">
|
@@ -1229,6 +1229,35 @@ env PGOPTIONS='-c geqo=off' psql
|
1229 | 1229 | </listitem>
|
1230 | 1230 | </varlistentry>
|
1231 | 1231 |
|
| 1232 | + <varlistentry> |
| 1233 | + <term>COMMIT_DELAY (<type>integer</type>)</term> |
| 1234 | + <listitem> |
| 1235 | + <para> |
| 1236 | + Time delay between writing a commit record to the WAL buffer and |
| 1237 | +flushing the buffer out to disk, in microseconds. A nonzero delay |
| 1238 | +allows multiple transactions to be committed with only one fsync, |
| 1239 | +if system load is high enough that additional transactions become |
| 1240 | +ready to commit within the given interval. But the delay is just |
| 1241 | +wasted time if no other transactions become ready to commit. |
| 1242 | +Therefore, the delay is only performed if at least COMMIT_SIBLINGS |
| 1243 | +other transactions are active at the instant that a backend has |
| 1244 | +written its commit record. |
| 1245 | + </para> |
| 1246 | + </listitem> |
| 1247 | + </varlistentry> |
| 1248 | + |
| 1249 | + <varlistentry> |
| 1250 | + <term>COMMIT_SIBLINGS (<type>integer</type>)</term> |
| 1251 | + <listitem> |
| 1252 | + <para> |
| 1253 | + Minimum number of concurrent open transactions to require before |
| 1254 | +performing the COMMIT_DELAY delay. A larger value makes it more |
| 1255 | +probable that at least one other transaction will become ready to |
| 1256 | +commit during the delay interval. |
| 1257 | + </para> |
| 1258 | + </listitem> |
| 1259 | + </varlistentry> |
| 1260 | + |
1232 | 1261 | <varlistentry>
|
1233 | 1262 | <term>WAL_BUFFERS (<type>integer</type>)</term>
|
1234 | 1263 | <listitem>
|
|