On Thu, Aug 25, 2016 at 12:21 PM, Simon Riggs <si...@2ndquadrant.com> wrote: > On 25 August 2016 at 02:31, Robert Haas <robertmh...@gmail.com> wrote: > >> Furthermore, there is an enforced, synchronous fsync at the end of >> every segment, which actually does hurt performance on write-heavy >> workloads.[2] Of course, if that were the only reason to consider >> increasing the segment size, it would probably make more sense to just >> try to push that extra fsync into the background, but that's not >> really the case. From what I hear, the gigantic number of files is a >> bigger pain point. > > I think we should fully describe the problem before finding a solution. > > This is too big a change to just tweak a value without discussing the > actual issue. > > And if the problem is as described, how can a change of x4 be enough > to make it worth the pain of change? I think you're already admitting > it can't be worth it by discussing initdb configuration. > > If we do have the pain of change, should we also consider making WAL > files variable length? What do we gain by having the files all the > same size? ISTM better to have WAL files that vary in length up to 1GB > in size. > > (This is all about XLOG_SEG_SIZE; I presume XLOG_BLCKSZ can stay as it > is, right?)
Avoiding variable sizes does avoid some failure modes on the filesystem side in the face of crashes/power loss. So making them variable size, while possible, wouldn't be simple at all (it would involve figuring out the way filesystems behave when facing crash when a file is changing in size). -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers