On Sat, Feb 13, 2016 at 11:31 AM, Andres Freund <and...@anarazel.de> wrote: > On 2016-02-13 11:10:58 -0500, Tom Lane wrote: >> Magnus Hagander <mag...@hagander.net> writes: >> > The big thing is, IIRC, that we turn off the optimizations in >> > min_wal_level. *most* people will see no impact of their regular >> > application runtime from that, but it might definitely have an effect on >> > data loads and such. For normal runtime, there should be very close to zero >> > difference, no? >> >> I was asking for a demonstration of that, not just handwaving. Even if >> it was measured years ago, I wouldn't assume the comparison would be >> the same on current Postgres. > > Well, let's look at what the difference between wal_level's are: > 1) the (currently broken) optimization of not WAL logging COPY et al, > for newly created relations. > 2) relation AccessExclusiveLocks are WAL logged on >= hot_standby > 3) Subtransaction assignment records are generated for >= hot_standby > after 64 records. > 4) checkpoints and bgwriter occasionally generate XLOG_RUNNING_XACTS > records > 5) btreevacuum() and _bt_getbuf() sometimes do additional WAL logging on > >= hot_standby > 6) Once per vacuum we issue a XLOG_HEAP2_CLEANUP_INFO > > > 1) obviously can have performance impact; but only in a relatively > narrow set of cases. I doubt any of the others really play that major a > role. But I really think minor efficiency differences are besides the > point. Making backups and replication easier has a far bigger positive > impact, for far more users.
I think that there are definitely people for whom #1 is an issue, but maybe that's not a sufficient reason not to change the default. As a thought experiment, how about teaching initdb how to tailor the configuration to a couple of common scenarios via some new flag? I'll call it --setup although that's probably not best. --setup=replication --- Preconfigure for replication. --setup=standalone --- Preconfigure for standalone mode. --setup=ephemeral --- Preconfigure for an ephemeral instance that doesn't need durability because we'll blow it up soon. Whichever mode we make the default, I think this kind of thing would make life easier for users. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (firstname.lastname@example.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers