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. (The already stated
fsync problem is also a linear effect but that reduces with WAL
segment size, hence the need for a trade-off and hence why
variable-size is preferable).
If we wish this feature to get committed ISTM that we should examine
server performance with a large fixed WAL segment size, so we can
measure the effects of this, particularly with regard to the poor user
that gets to add a new WAL file. ISTM that may reveal more work is
needed to be handed off to the WALWriter process (or other
issues/solutions).
Once we have that information we can consider whether to apply this
patch, so until then, -1 to apply this, though I am hopeful that this
can be applied in this release.
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
