|
|
|
|
@ -1,4 +1,4 @@ |
|
|
|
|
<!-- $PostgreSQL: pgsql/doc/src/sgml/config.sgml,v 1.160 2007/12/11 20:07:31 alvherre Exp $ --> |
|
|
|
|
<!-- $PostgreSQL: pgsql/doc/src/sgml/config.sgml,v 1.161 2008/01/21 03:28:42 tgl Exp $ --> |
|
|
|
|
|
|
|
|
|
<chapter Id="runtime-config"> |
|
|
|
|
<title>Server Configuration</title> |
|
|
|
|
@ -1192,17 +1192,16 @@ SET ENABLE_SEQSCAN TO OFF; |
|
|
|
|
<title>Background Writer</title> |
|
|
|
|
|
|
|
|
|
<para> |
|
|
|
|
Beginning in <productname>PostgreSQL</> 8.0, there is a separate server |
|
|
|
|
There is a separate server |
|
|
|
|
process called the <firstterm>background writer</>, whose function |
|
|
|
|
is to issue writes of <quote>dirty</> shared buffers. The intent is |
|
|
|
|
that server processes handling user queries should seldom or never have |
|
|
|
|
to wait for a write to occur, because the background writer will do it. |
|
|
|
|
However there is a net overall |
|
|
|
|
increase in I/O load, because where a repeatedly-dirtied page might |
|
|
|
|
before have been written only once per checkpoint interval, the |
|
|
|
|
increase in I/O load, because a repeatedly-dirtied page might |
|
|
|
|
otherwise be written only once per checkpoint interval, but the |
|
|
|
|
background writer might write it several times in the same interval. |
|
|
|
|
In most situations a continuous low load is preferable to periodic |
|
|
|
|
spikes, but the parameters discussed in this subsection can be used to |
|
|
|
|
The parameters discussed in this subsection can be used to |
|
|
|
|
tune the behavior for local needs. |
|
|
|
|
</para> |
|
|
|
|
|
|
|
|
|
@ -1253,12 +1252,14 @@ SET ENABLE_SEQSCAN TO OFF; |
|
|
|
|
</indexterm> |
|
|
|
|
<listitem> |
|
|
|
|
<para> |
|
|
|
|
Unless limited by <varname>bgwriter_lru_maxpages</>, the number |
|
|
|
|
of dirty buffers written in each round is determined by reference |
|
|
|
|
to the number of new buffers that have been needed by server |
|
|
|
|
processes during recent rounds. This number is multiplied by |
|
|
|
|
<varname>bgwriter_lru_multiplier</> to arrive at the estimate |
|
|
|
|
of the number of buffers that will be needed during the next round. |
|
|
|
|
The number of dirty buffers written in each round is based on the |
|
|
|
|
number of new buffers that have been needed by server processes |
|
|
|
|
during recent rounds. The average recent need is multiplied by |
|
|
|
|
<varname>bgwriter_lru_multiplier</> to arrive at an estimate of the |
|
|
|
|
number of buffers that will be needed during the next round. Dirty |
|
|
|
|
buffers are written until there are that many clean, reusable buffers |
|
|
|
|
available. (However, no more than <varname>bgwriter_lru_maxpages</> |
|
|
|
|
buffers will be written per round.) |
|
|
|
|
Thus, a setting of 1.0 represents a <quote>just in time</> policy |
|
|
|
|
of writing exactly the number of buffers predicted to be needed. |
|
|
|
|
Larger values provide some cushion against spikes in demand, |
|
|
|
|
|