On Tue, Sep 20, 2016 at 4:42 PM, Andres Freund <and...@anarazel.de> wrote: > On 2016-09-20 16:32:46 -0400, Robert Haas wrote: >> > Requiring a non-default compile time or even just cluster creation time >> > option for tuning isn't something worth expanding energy on imo. >> >> I don't agree. The latency requirements on an archive_command when >> you're churning out 16MB files multiple times per second are insanely >> tight, and saying that we shouldn't increase the size because it's >> better to go redesign a bunch of other things that will eventually >> *maybe* remove the need for archive_command does not seem like a >> reasonable response. > > Oh, I'm on board with increasing the default size a bit. A different > default size isn't a non-default compile time option anymore though, and > I don't think 1GB is a reasonable default.
But that's not the question. What Peter said was: "maybe we should at least *allow* some larger sizes, for testing out". I see very little merit in restricting the values that people can set via configure. That just makes life difficult. If a user picks a setting that doesn't perform well, oops. > Running multiple archive_commands concurrently - pretty easy to > implement - isn't the same as removing the need for archive command. I'm > pretty sure that continously,and if necessary concurrently, archiving a > bunch of 64MB files is going to work better than irregularly > creating / transferring 1GB files. I'm not trying to block you from implementing parallel archiving, but right now we don't have it. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers