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 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
