Re: increasing the default WAL segment size

On Thu, Aug 25, 2016 at 1:05 PM, Magnus Hagander <magnus(at)hagander(dot)net> wrote:
>> 1. Do nothing. So far, I don't see anybody arguing for that.
>>
>> 2. Change the default to 64MB and call it good. This idea seems to
>> have considerable support.
>>
>> 3. Allow initdb-time configurability but keep the default at 16MB. I
>> don't see any support for this. There is clearly support for
>> configurability, but I don't see anyone arguing that the current
>> default is preferable, unless that is what you are arguing.
>>
>> 4. Change the default to 64MB and also allow initdb-time
>> configurability. This option also appears to enjoy substantial
>> support, perhaps more than #2. Magnus seemed to be arguing that this
>> is preferable to #2, because then it's easier for people to change the
>> setting back if someone discovers a case where the higher default is a
>> problem; Tom, on the other hand, seems to think this is overkill.
>
> I was not arguing for #4 over #2, at least not strongly. I think #2 is fine,
> and I think #4 are fine. #4 allows a way out, but it's not *that* important
> unless we go *beyond* 64Mb.

OK, thanks for clarifying. I can't see going beyond 64MB by default
when we're shipping max_wal_size=1GB. In another 20 years when
PB-size thumb drives are commonplace we might reconsider.

> I was mainly arguing that we can't claim "it has a configure switch so it's
> kinda configurable" as a way out. If we want it configurable *at all*, it
> should be an initdb switch. If we are confident in our defaults, it doesn't
> have to be.
>
> I agree that #4 is best. I'm not sure it's worth the cost. I'm not worried
> at all about the risk of master/slave sync thing, per previous statement.
> But if it does have performance implications, per Andres suggestion, then
> making it configurable at initdb time probably comes with a cost that's not
> worth paying.

At this point it's hard to judge, because we don't have any idea what
the cost might be. I guess if we want to pursue this approach,
somebody will have to code it up and benchmark it. But what I'm
inclined to do for starters is put together a patch to go from 16MB ->
64MB. Committing that early this cycle will give us time to
reconsider if that turns out to be painful for reasons we haven't
thought of yet. And give tool authors time to make adjustments, if
any are needed.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company