On Tue, Mar 21, 2017 at 8:10 PM, Stephen Frost <sfr...@snowman.net> wrote: >> We've already >> created quite a few incompatibilities in this release, and I'm not >> entirely eager to just keep cranking them out at top speed. > > That position would seem to imply that you're in favor of keeping the > current default of 16MB, but that doesn't make sense given that you > started this discussion advocating to make it larger. Changing your > position is certainly fine, but it'd be good to be more clear if that's > what you meant here or if you were just referring to the file naming > scheme but you do still want to increase the default size.
To be honest, I'd sort of forgotten about the change which is the nominal subject of this thread - I was more focused on the patch, which makes it configurable. I was definitely initially in favor of raising the value, but I got cold feet, a bit, when Alvaro pointed out that going to 64MB would require a substantial increase in min_wal_size. I'm not sure people with small installations will appreciate seeing that value cranked up from 5 segments * 16MB = 80MB to, say, 3 segments * 64MB = 192MB. That's an extra 100+ MB of space that doesn't really do anything for you. And nobody's done any benchmarking to see whether having only 3 segments is even a workable, performant configuration, so maybe we'll end up with 5 * 64MB = 320MB by default. I'm a little worried that this whole question of changing the file naming scheme is a diversion which will result in torpedoing any chance of getting some kind of improvement here for v11. I don't think the patch is all that far from being committable but it's not going to get there if we start redesigning the world around it. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
