Re: Improve This Sentence? - Mailing list pgsql-docs

From Dave Cramer
Subject Re: Improve This Sentence?
Date
Msg-id CADK3HHK-w1TrfuWXcy4qFr9NxuiUcYoHRY__vhoH5qtDYcChJg@mail.gmail.com
Whole thread Raw
In response to Re: Improve This Sentence?  (Michael Paquier <michael@paquier.xyz>)
Responses Re: Improve This Sentence?  (Michael Paquier <michael@paquier.xyz>)
List pgsql-docs


On Sun, 12 Apr 2020 at 20:57, Michael Paquier <michael@paquier.xyz> wrote:
On Fri, Apr 10, 2020 at 06:32:05PM +0000, PG Doc comments form wrote:
> On Linux and POSIX platforms checkpoint_flush_after allows to force the OS
> that pages written by the checkpoint should be flushed to disk after a
> configurable number of bytes.
>
> I think I have an idea what it says, but saw some discussion to this very
> issue.  Can it be re-written?

How would you suggest to rewrite it?

This is interesting here is the entire paragraph in question from 29.4. WAL Configuration

On Linux and POSIX platforms checkpoint_flush_after allows to force the OS that pages written by the checkpoint should be flushed to disk after a configurable number of bytes. Otherwise, these pages may be kept in the OS's page cache, inducing a stall when fsync is issued at the end of a checkpoint. This setting will often help to reduce transaction latency, but it also can have an adverse effect on performance; particularly for workloads that are bigger than shared_buffers, but smaller than the OS's page cache.

and here is another paragraph which is much better from 19.5.2. Checkpoints 

Whenever more than this amount of data has been written while performing a checkpoint, 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 the 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 shared_buffers, but smaller than the OS's page cache, where performance might degrade. This setting may have no effect on some platforms. If this value is specified without units, it is taken as blocks, that is BLCKSZ bytes, typically 8kB. The valid range is between 0, which disables forced writeback, and 2MB. The default is 256kB on Linux, 0 elsewhere. (If BLCKSZ is not 8kB, the default and maximum values scale proportionally to it.) This parameter can only be set in the postgresql.conf file or on the server command line.

Ironically the first one above is supposed to be providing more clarity if you can believe:
For additional information on tuning these settings, see Section 29.4.

Clearly just copying the text from 19.5.2 to 29.4 is an improvement. I'd be somewhat loathe to be that repetitive but honestly I don't have a better suggestion

Dave


pgsql-docs by date:

Previous
From: Tom Lane
Date:
Subject: Re: Getting our tables to render better in PDF output
Next
From: Corey Huinker
Date:
Subject: Re: Getting our tables to render better in PDF output