* 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. > 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, and I came to that conclusion based on the previously published work when the feature was being developed, which was a few percent, as I recall, though I'd be fine with having it be the default even if it was 5%. At what point would you say we shouldn't have the default be to have checksums enabled? 1%? 5%? 10%? All that said, to be clear, I don't have any objection to Tomas (or whomever) doing performance testing of this case if he's interested and has time, but that I don't feel we really need a huge analysis of this. We did an analysis when the feature was developed and I doubt we would have been able to even get it included if it resulted in a 10% or more performance hit, though it wasn't that high, as I recall. Thanks! Stephen
signature.asc
Description: Digital signature