Re: Checksums by default?

On 21/01/17 18:15, Stephen Frost wrote:
> * Petr Jelinek (petr(dot)jelinek(at)2ndquadrant(dot)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