Re: [HACKERS] increasing the default WAL segment size - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: [HACKERS] increasing the default WAL segment size
Date
Msg-id CAB7nPqRjxUfeVNVrAzN-P6gi4Z8iTg-Tx8v0JhyaP-Wa8sy7-A@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] increasing the default WAL segment size  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
On Thu, Jan 5, 2017 at 12:33 AM, Robert Haas <robertmhaas@gmail.com> wrote:
> On Wed, Jan 4, 2017 at 9:47 AM, Simon Riggs <simon@2ndquadrant.com> wrote:
>> On 4 January 2017 at 13:57, Robert Haas <robertmhaas@gmail.com> wrote:
>>> On Wed, Jan 4, 2017 at 3:05 AM, Simon Riggs <simon@2ndquadrant.com> wrote:
>>>> Strange response. Nothing has been assumed. I asked for tests and you
>>>> provided measurements.
>>>
>>> Sure, of zero-filling a file with dd.  But I also pointed out that in
>>> a real PostgreSQL cluster, the change could actually *reduce* latency.
>>
>> I think we are talking at cross purposes. We agree that the main
>> change is useful, but it causes another problem which I can't see how
>> you can characterize as reduced latency, based upon your own
>> measurements.
>
> Zero-filling files will take longer if the files are bigger.  That
> will increase latency.  But we will also have fewer forced
> end-of-segment syncs.  That will reduce latency.  Which effect is
> bigger?

It depends on if the environment is CPU-bounded or I/O bounded. If CPU
is at its limit, zero-filling takes time. If that's the I/O, fsync()
would take longer to complete.
-- 
Michael



pgsql-hackers by date:

Previous
From: Tomas Vondra
Date:
Subject: Re: [HACKERS] Replication/backup defaults
Next
From: Kouhei Kaigai
Date:
Subject: Re: [HACKERS] PassDownLimitBound for ForeignScan/CustomScan [take-2]