Re: [HACKERS] segment size depending *_wal_size defaults (wasincreasing the default WAL segment size)
От | Peter Eisentraut |
---|---|
Тема | Re: [HACKERS] segment size depending *_wal_size defaults (wasincreasing the default WAL segment size) |
Дата | |
Msg-id | 6f260996-e603-31e0-cc22-7393c73011cd@2ndquadrant.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] segment size depending *_wal_size defaults (wasincreasing the default WAL segment size) (Andres Freund <andres@anarazel.de>) |
Ответы |
Re: [HACKERS] segment size depending *_wal_size defaults (wasincreasing the default WAL segment size)
|
Список | pgsql-hackers |
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. 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. Right now, we have max_wal_size = 1GB by default. What should the behavior be for wal_segment_size = 1GB? > 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. 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. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
В списке pgsql-hackers по дате отправления: