Re: segment size depending *_wal_size defaults (was increasing the default WAL segment size)

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