Whenever more than <varname>bgwriter_flush_after</varname> bytes have
        been written by the bgwriter, attempt to force the OS to issue these
        writes to the underlying storage.  Doing so will limit the amount of
        dirty data in the kernel's page cache, reducing the likelihood of
        stalls when an fsync is issued at the end of a checkpoint, or when
        the OS writes data back  in larger batches in the background.  Often
        that will result in greatly reduced transaction latency, but there
        also are some cases, especially with workloads that are bigger than
        <xref linkend="guc-shared-buffers">, but smaller than the OS's page
        cache, where performance might degrade.  This setting may have no
        effect on some platforms.  <literal>0</literal> disables controlled
        writeback. The default is <literal>256Kb</> on Linux, <literal>0</>
        otherwise. This parameter can only be set in the
        <filename>postgresql.conf</> file or on the server command line.

(plus adjustments for the other gucs)

Some suggestions:

What about the maximum value?

If the default is in pages, maybe you could state it and afterwards translate it in size.

"The default is 64 pages on Linux (usually 256Kb)..."

The text could say something about sequential writes performance because pages are sorted.., but that it is lost for large bases and/or short checkpoints ?


Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to