Re: increasing the default WAL segment size
От | Simon Riggs |
---|---|
Тема | Re: increasing the default WAL segment size |
Дата | |
Msg-id | CANP8+j+op_1nzLnk7sH+a1G1pq_46RUjaLyxWV=c0Cdoymxf8A@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] increasing the default WAL segment size (tushar <tushar.ahuja@enterprisedb.com>) |
Список | pgsql-hackers |
On 5 April 2017 at 06:04, Beena Emerson <memissemerson@gmail.com> wrote: >> >> No commitment yet to increasing wal-segsize in the way this patch has >> >> it. >> >> >> > >> > What part of patch you don't like and do you have any suggestions to >> > improve the same? >> >> I think there are still some questions and disagreements about how it >> should behave. > > > The WALfilename - LSN mapping disruption for higher values you mean? Is > there anything else I have missed? I see various issues raised but not properly addressed 1. we would need to drop support for segment sizes < 16MB unless we adopt a new incompatible filename format. I think at 16MB the naming should be the same as now and that WALfilename -> LSN is very important. For this release, I think we should just allow >= 16MB and avoid the issue thru lack of time. 2. It's not clear to me the advantage of being able to pick varying filesizes. I see great disadvantage in having too many options, which greatly increases the chance of incompatibility, annoyance and breakage. I favour a small number of values that have been shown by testing to be sweet spots in performance and usability. (1GB has been suggested) 3. New file allocation has been a problem raised with this patch for some months now. Lack of clarity and/or movement on these issues is very, very close to getting the patch rejected now. Let's not approach this with the viewpoint that I or others want it to be rejected, lets work forwards and get some solid changes that will improve the world without causing problems. -- Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
В списке pgsql-hackers по дате отправления: