Re: auto-sizing wal_buffers
От | Jeff Janes |
---|---|
Тема | Re: auto-sizing wal_buffers |
Дата | |
Msg-id | AANLkTimZVFNcCuQ+iDCs2aCQ0HXyf3WiAkYmUR6S9Vsc@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: auto-sizing wal_buffers (Josh Berkus <josh@agliodbs.com>) |
Список | pgsql-hackers |
On Sat, Jan 15, 2011 at 2:34 PM, Josh Berkus <josh@agliodbs.com> wrote: > On 1/14/11 10:51 PM, Greg Smith wrote: >> >> ! Since the data is written out to disk at every transaction >> commit, >> ! the setting many only need to be be large enough to hold the >> amount >> ! of WAL data generated by one typical transaction. Larger values, >> ! typically at least a few megabytes, can improve write performance >> ! on a busy server where many clients are committing at once. >> ! Extremely large settings are unlikely to provide additional >> benefit. > > I think we can be more specific on that last sentence; is there even any > *theoretical* benefit to settings above 16MB, the size of a WAL segment? I would turn it around and ask if there is any theoretical reason it would not benefit? (And if so, can they be cured soon?) > Certainly there have been no test results to show any. Did the tests show steady improvement up to 16MB and then suddenly hit a wall? (And in which case, were they recompiled at a larger segment size and repeated?) Or did improvement just peter out because 16MB is really quite a bit and there was just no need for it to be larger independent of segment size? Cheers, Jeff
В списке pgsql-hackers по дате отправления: