On 2 January 2017 at 21:23, Jim Nasby <jim.na...@bluetreble.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. (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

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

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to