Re: [HACKERS] segment size depending *_wal_size defaults (wasincreasing the default WAL segment size) - Mailing list pgsql-hackers

From Andres Freund
Subject Re: [HACKERS] segment size depending *_wal_size defaults (wasincreasing the default WAL segment size)
Date
Msg-id 20170830152733.4nvjd26fo7w65dsz@alap3.anarazel.de
Whole thread Raw
In response to Re: [HACKERS] segment size depending *_wal_size defaults (wasincreasing the default WAL segment size)  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
List pgsql-hackers
Hi,


To make it clear: I don't have a strong opinion on these, I'm happy
enough to commit the patch as is, minus one unrelated change. I just
think it should be discussed.


On 2017-08-30 07:01:54 -0400, Peter Eisentraut wrote:
> On 8/30/17 00:45, Andres Freund wrote:
> > 1) Currently the default for {min,max}_wal_size depends on the segment
> >    size. Given that the segment size is about to be configurable, that
> >    seems confusing.
> 
> On the one hand, I agree that it seems confusing and unnecessary to vary
> this with the segment size.  On the other hand, the problem is that if
> the segment size is larger than the default max_wal_size, we have to do
> something different anyway.

Well, rounding up to two segments, is different than rounding up to
64GB... I think there's a fair argument to be made that that's confusing
too.


> Also, the reason for wanting a larger segment size is that you expect
> a lot of WAL, so setting max_wal_size larger by default caters to
> that.

This I find unconvincing. If we want more autotuning, we should do that,
rather than define random things as that.


> Right now, we have max_wal_size = 1GB by default.  What should the
> behavior be for wal_segment_size = 1GB?

2GB.



> > 2) Currently wal_segment_size is measured in GUC_UNIT_XBLOCKS, which
> >    requires us to keep two copies of the underlying variable, one in
> >    XBLOCKS one in bytes. I'd rather just have the byte variant.
> 
> It seems to me that one could structure the code to make do with the
> existing variable. I had a brief look at the patch, and I think some
> more imaginative refactoring is possible.

That'd add yet more instructions to tight spinlock'ed paths, so I'm
loathe to do so. Or maybe I'm just missing what you're thinking about?


> If we want/need to change it, I'd prefer using the _KB or _MB
> variants, so as to not to restrict future size limits too much.

I'm a bit surprised at this one - if we want to add larger segment size
limits (which I don't think are useful), wouldn't it be just as
appropriate to extend the GUC infrastructure?


Greetings,

Andres Freund



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: [HACKERS] Parallel worker error
Next
From: Robert Haas
Date:
Subject: Re: [HACKERS] Hash Functions