On Wed, Aug 24, 2016 at 08:52:20PM -0700, Andres Freund wrote: > On 2016-08-24 23:26:51 -0400, Robert Haas wrote: > > On Wed, Aug 24, 2016 at 10:54 PM, Andres Freund <and...@anarazel.de> wrote: > > > and I'm also rather doubtful that it's actually without overhead. > > > > Really? Where do you think the overhead would come from? > > ATM we do a math involving XLOG_BLCKSZ in a bunch of places (including > doing a lot of %). Some of that happens with exclusive lwlocks held, and > some even with a spinlock held IIRC. Making that variable won't be > free. Whether it's actually measurabel - hard to say. I do remember > Heikki fighting hard to simplify some parts of the critical code during > xlog scalability stuff, and that that even involved moving minor amounts > of math out of critical sections.
I think Robert made a good case that high-volume servers might want a larger WAL segment size, but as Andres pointed out, there are performance concerns. Those might be minimized by requiring the segment size to be a 2x multiple of 16MB. Another issue is that many users are coming from database products that have significant performance hits in switching WAL files so they might be tempted to set very high segment sizes in inappropriate cases. -- Bruce Momjian <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + As you are, so once was I. As I am, so you will be. + + Ancient Roman grave inscription + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers