Re: [HACKERS] Checksums by default?

* Petr Jelinek (petr.jelinek@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