Petr, * Petr Jelinek (petr.jeli...@2ndquadrant.com) wrote: > On 21/01/17 16:40, Stephen Frost wrote: > > * Petr Jelinek (petr.jeli...@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
signature.asc
Description: Digital signature