On Thu, Nov 12, 2020 at 05:25:30PM +0000, Chris Wilson wrote:
> Hi Bruce,
>
> Thanks, I absolutely agree that this documentation needs to explain properly
> how the bgwriter works. Your latest patch looks good, it significantly
> improves
> this section of the manual. I would just suggest changing "non-dirty" to
> "clean" in "When the number of non-dirty shared buffers appears to be
> insufficient", as this makes the language simpler and avoids introducing
> another new term (non-dirty, which means the same as clean).
OK, done. I wasn't sure 'clean' would be assumed to be non-dirty, but you
are right the language is clearer with 'clean'. (I was afraid 'clean'
would be assumed to be 'empty'.)
--
Bruce Momjian <br...@momjian.us> https://momjian.us
EnterpriseDB https://enterprisedb.com
The usefulness of a cup is in its emptiness, Bruce Lee
diff --git a/doc/src/sgml/config.sgml b/doc/src/sgml/config.sgml
index f043433e31..a632cf98ba 100644
--- a/doc/src/sgml/config.sgml
+++ b/doc/src/sgml/config.sgml
@@ -2146,8 +2146,11 @@ include_dir 'conf.d'
There is a separate server
process called the <firstterm>background writer</firstterm>, whose function
is to issue writes of <quote>dirty</quote> (new or modified) shared
- buffers. It writes shared buffers so server processes handling
- user queries seldom or never need to wait for a write to occur.
+ buffers. When the number of clean shared buffers appears to be
+ insufficient, the background writer writes some dirty buffers to the
+ file system and marks them as clean. This reduces the likelihood
+ that server processes handling user queries will be unable to find
+ clean buffers and have to write dirty buffers themselves.
However, the background writer does cause a net overall
increase in I/O load, because while a repeatedly-dirtied page might
otherwise be written only once per checkpoint interval, the
