Petr,
* Petr Jelinek (petr.jelinek@2ndquadrant.com) wrote:
> On 21/01/17 16:40, Stephen Frost wrote:
> > * Petr Jelinek (petr.jelinek@2ndquadrant.com) wrote:
> >> On 21/01/17 11:39, Magnus Hagander wrote:
> >>> Is it time to enable checksums by default, and give initdb a switch to
> >>> turn it off instead?
> >>
> >> I'd like to see benchmark first, both in terms of CPU and in terms of
> >> produced WAL (=network traffic) given that it turns on logging of hint bits.
> >
> > Benchmarking was done previously, but I don't think it's really all that
> > relevant, we should be checksum'ing by default because we care about the
> > data and it's hard to get checksums enabled on a running system.
>
> I do think that performance implications are very relevant. And I
> haven't seen any serious benchmark that would incorporate all current
> differences between using and not using checksums.
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.
There are interesting arguments to be made about if checksum'ing is
every worthwhile at all (some seem to see that the feature is entirely
useless and we should just rip that code out, but I don't agree with
that), or if we should just always enable it (because fewer options is a
good thing and we care about our user's data and checksum'ing is worth
the performance hit if it's a small hit; I'm more on the fence when it
comes to this one as I have heard people say that they've run into cases
where it does enough of a difference in performance to matter for them).
We don't currently configure the defaults for any system to be the
fastest possible performance, or we wouldn't have changed wal_level and
we would have move aggressive settings for things like default work_mem,
maintenance_work_mem, shared_buffers, max_wal_size,
checkpoint_completion_target, all of the autovacuum settings,
effective_io_concurrency, effective_cache_size, etc, etc.
> 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.
Thanks!
Stephen