From: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
---|---|
To: | Simon Riggs <simon(at)2ndquadrant(dot)com> |
Cc: | Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Beena Emerson <memissemerson(at)gmail(dot)com> |
Subject: | Re: increasing the default WAL segment size |
Date: | 2017-01-03 13:45:31 |
Message-ID: | CAA4eK1LehsxSBsPdqu8cC=S=x6Odb=VwUwcdqH4veor7ZY_Fig@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Jan 3, 2017 at 6:41 PM, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
> On 2 January 2017 at 21:23, Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)com> wrote:
>
>> It's not clear from the thread that there is consensus that this feature is desired. In particular, the performance aspects of changing segment size from a C constant to a variable are in question. Someone with access to large hardware should test that. Andres[1] and Robert[2] did suggest that the option could be changed to a bitshift, which IMHO would also solve 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
From | Date | Subject | |
---|---|---|---|
Next Message | Simon Riggs | 2017-01-03 13:59:44 | Re: increasing the default WAL segment size |
Previous Message | Dilip Kumar | 2017-01-03 13:42:04 | Re: multivariate statistics (v19) |