On 21/01/17 17:51, Stephen Frost wrote: > * Petr Jelinek (petr.jeli...@2ndquadrant.com) wrote: >> On 21/01/17 17:31, Stephen Frost wrote: >>> This is just changing the *default*, not requiring checksums to always >>> be enabled. We do not hold the same standards for our defaults as we do >>> for always-enabled code, for clear reasons- not every situation is the >>> same and that's why we have defaults that people can change. >> >> I can buy that. If it's possible to turn checksums off without >> recreating data directory then I think it would be okay to have default on. > > I'm glad to hear that. > >>>> The change of wal_level was supported by benchmark, I think it's >>>> reasonable to ask for this to be as well. >>> >>> No, it wasn't, it was that people felt the cases where changing >>> wal_level would seriously hurt performance didn't out-weigh the value of >>> making the change to the default. >> >> Really? > > Yes. > >> https://www.postgresql.org/message-id/d34ce5b5-131f-66ce-f7c5-eb406dbe0...@2ndquadrant.com > > From the above link: > >> So while it'd be trivial to construct workloads demonstrating the >> optimizations in wal_level=minimal (e.g. initial loads doing CREATE >> TABLE + COPY + CREATE INDEX in a single transaction), but that would be >> mostly irrelevant I guess. > >> Instead, I've decided to run regular pgbench TPC-B-like workload on a >> bunch of different scales, and measure throughput + some xlog stats with >> each of the three wal_level options. > > In other words, there was no performance testing of the cases where > wal_level=minimal (the old default) optimizations would have been > compared against wal_level > minimal. > > I'm quite sure that the performance numbers for the CREATE TABLE + COPY > case with wal_level=minimal would have been *far* better than for > wal_level > minimal.
Which is random usecase very few people do on regular basis. Checksums affect *everybody*. What the benchmarks gave us is a way to do informed decision for common use. All I am asking for here is to be able to do informed decision as well. -- Petr Jelinek http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
