Re: increasing the default WAL segment size
От | Andres Freund |
---|---|
Тема | Re: increasing the default WAL segment size |
Дата | |
Msg-id | 20160920204201.irp7bpxiyejyv2vy@alap3.anarazel.de обсуждение исходный текст |
Ответ на | Re: increasing the default WAL segment size (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: increasing the default WAL segment size
|
Список | pgsql-hackers |
On 2016-09-20 16:32:46 -0400, Robert Haas wrote: > > Requiring a non-default compile time or even just cluster creation time > > option for tuning isn't something worth expanding energy on imo. > > I don't agree. The latency requirements on an archive_command when > you're churning out 16MB files multiple times per second are insanely > tight, and saying that we shouldn't increase the size because it's > better to go redesign a bunch of other things that will eventually > *maybe* remove the need for archive_command does not seem like a > reasonable response. Oh, I'm on board with increasing the default size a bit. A different default size isn't a non-default compile time option anymore though, and I don't think 1GB is a reasonable default. Running multiple archive_commands concurrently - pretty easy to implement - isn't the same as removing the need for archive command. I'm pretty sure that continously,and if necessary concurrently, archiving a bunch of 64MB files is going to work better than irregularly creating / transferring 1GB files. Andres
В списке pgsql-hackers по дате отправления: