On 21/01/17 18:15, Stephen Frost wrote: > * Petr Jelinek (petr.jeli...@2ndquadrant.com) wrote: >> On 21/01/17 17:51, Stephen Frost wrote: >>> 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*. > > It's not a 'random usecase very few people do on a regular basis', it's > a different usecase which a subset of our users do. I agree that > changing the default for checksums would affect everyone who uses just > the defaults. > > What I think is different about checksums, really, is that you have to > pass an option to initdb to enable them. That's right from a technical > perspective, but I seriously doubt everyone re-reads the 'man' page for > initdb when they're setting up a new cluster, and if they didn't read > the release notes for that particular release where checksums were > introduced, they might not be aware that they exist or that they're > defaulted to off. > > Values in postgresql.conf, at least in my experience, get a lot more > regular review as there's always things changing there from > release-to-release and anyone even slightly experienced with PG knows > that our defaults in postgresql.conf pretty much suck and have to be > adjusted. I expect we'd see a lot more people using checksums if they > were in postgresql.conf somehow. I don't have any particular answer to > that problem, just thought it interesting to consider how flags to > initdb differ from postgresql.conf configuration options.
So in summary "postgresql.conf options are easy to change" while "initdb options are hard to change", I can see this argument used both for enabling or disabling checksums by default. As I said I would be less worried if it was easy to turn off, but we are not there afaik. And even then I'd still want benchmark first. > >> 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. > > From above: > >>>>>> 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. > > In other words, the change of the *default* for checksums, at least in > my view, is well worth the performance impact. > As we don't know the performance impact is (there was no benchmark done on reasonably current code base) I really don't understand how you can judge if it's worth it or not. I stand by the opinion that changing default which affect performance without any benchmark is bad idea. And for the record, I care much less about overall TPS, I care a lot more about amount of WAL produced because in 90%+ environments that I work with any increase in WAL amount means at least double the increase in network bandwidth due to replication. -- Petr Jelinek http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (firstname.lastname@example.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers