On Thu, Nov 12, 2020 at 02:40:04PM +0000, Chris Wilson wrote:
> Hi Bruce,
>
> Thanks, yes I agree that that is much clearer. However when you say:
>
>
> When the percentage of dirty shared buffers is high, the background writer
> writes some of them to the file system...
>
>
> I haven't seen anything about a minimum percentage before the bgwriter kicks
> in, is that really the case? How is it configured?
Yes, I see your point. My language was not accurate, and it didn't
match the actual background writer tuning parameters below this text.
Here is an updated doc patch.
I agree this text should be as clear as possible because there is no way
to properly tune the background writer parameters unless we explain how
it works. It is good you noticed this.
--
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..8a29c90fdc 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 non-dirty 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
