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

On Wed, Aug 30, 2017 at 6:45 AM, Andres Freund <andres(at)anarazel(dot)de> wrote:

> On 2017-08-30 12:52:26 +0900, Michael Paquier wrote:
> > On Wed, Aug 30, 2017 at 11:20 AM, Peter Eisentraut
> > <peter(dot)eisentraut(at)2ndquadrant(dot)com> wrote:
> > > On 8/29/17 20:36, Andres Freund wrote:
> > >> So the question is whether we want {max,min}_wal_size be sized in
> > >> multiples of segment sizes or as a proper byte size. I'm leaning
> > >> towards the latter.
> > >
> > > I'm not sure what the question is or what its impact would be.
> >
> > FWIW, I get the question as: do we want the in-memory values of
> > min/max_wal_size to be calculated in MB (which is now the case) or
> > just bytes. Andres tends for using bytes.
>
> Not quite. There's essentially two things:
>
> 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.
> 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.
>

I'd say we definitely want the "user interface" to be in
bytes(/mbytes/gbytes etc). We used to have that in segments and it was
quite confusing for a lot of new uers, and seemed very silly...

Also agreed that (1) above seems very confusing. Going to using bytes all
the way seems a lot more clear.

--
Magnus Hagander
Me: https://www.hagander.net/ <http://www.hagander.net/>
Work: https://www.redpill-linpro.com/ <http://www.redpill-linpro.com/>