On Wed, Aug 24, 2016 at 10:31 PM, Robert Haas <robertmh...@gmail.com> wrote: > 1. Transaction rates are vastly higher these days. In 1999, I think > we were still limited to ~2^32 transactions during the entire lifetime > of the server; transaction ID wraparound hadn't been invented yet.[1] > Today, some installations do that many write transactions in under a > week. The practical consequence of this is that WAL files fill up in > extremely short periods of time. Some users generate multiple > terabytes of WAL per day, which means they are generating - and very > likely archiving - WAL files a rate of greater than 1 per second! > That poses multiple problems. For example, if your archive command > happens to involve ssh, you might run into trouble because of this > sort of thing: > > [rhaas pgsql]$ /usr/bin/time ssh hydra true > 1.57 real 0.00 user 0.00 sys ... > Considering those three factors, I think we should consider pushing > the default value up somewhat higher for v10. Reverting to the 64MB > size that we had prior to 47937403676d913c0e740eec6b85113865c6c8ab > sounds pretty reasonable. Users with really high transaction rates > might even prefer a higher value (e.g. 256MB, 1GB) but that's hardly > practical for small installs given our default of max_wal_size = 1GB. > Possibly it would make sense for this to be configurable at initdb > time instead of requiring a recompile; we probably don't save any > significant number of cycles by compiling this into the server.
FWIW, +1 We're already hurt by the small segments due to a similar phenomenon as the ssh case: TCP slow start. Designing the archive/recovery command to work around TCP slow start is quite complex, and bigger segments would just be a better thing. Not to mention that bigger segments compress better. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers