Re: [HACKERS] increasing the default WAL segment size
От | Amit Kapila |
---|---|
Тема | Re: [HACKERS] increasing the default WAL segment size |
Дата | |
Msg-id | CAA4eK1LehsxSBsPdqu8cC=S=x6Odb=VwUwcdqH4veor7ZY_Fig@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] increasing the default WAL segment size (Simon Riggs <simon@2ndquadrant.com>) |
Ответы |
Re: [HACKERS] increasing the default WAL segment size
|
Список | pgsql-hackers |
On Tue, Jan 3, 2017 at 6:41 PM, Simon Riggs <simon@2ndquadrant.com> wrote: > On 2 January 2017 at 21:23, Jim Nasby <Jim.Nasby@bluetreble.com> wrote: > >> It's not clear from the thread that there is consensus that this feature is desired. In particular, the performance aspectsof changing segment size from a C constant to a variable are in question. Someone with access to large hardware shouldtest that. Andres[1] and Robert[2] did suggest that the option could be changed to a bitshift, which IMHO would alsosolve some sanity-checking issues. > > Overall, Robert has made a good case. The only discussion now is about > the knock-on effects it causes. > > One concern that has only barely been discussed is the effect of > zero-ing new WAL files. That is a linear effect and will adversely > effect performance as WAL segment size increases. > Sorry, but I am not able to understand why this is a problem? The bigger the size of WAL segment, lesser the number of files. So IIUC, then it can only impact if zero-ing two 16MB files is cheaper than zero-ing one 32MB file. Is that your theory or you have something else in mind? -- With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: