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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers