On Fri, Jan 8, 2021 at 4:57 PM Bruce Momjian <br...@momjian.us> wrote: > > On Fri, Jan 8, 2021 at 09:46:58AM -0500, David Steele wrote: > > On 1/8/21 5:03 AM, Andres Freund wrote: > > > On Fri, Jan 8, 2021, at 01:53, Laurenz Albe wrote: > > > > > > > > The serious crowd are more likely to choose a non-default setting > > > > to avoid paying the price for a feature that they don't need. > > > > > > I don't really buy this argument. That way we're going to have an ever > > > growing set of things that need to be tuned to have a database that's > > > usable in an even halfway busy setup. That's unavoidable in some cases, > > > but it's a significant cost across use cases. > > > > > > Increasing the overhead in the default config from one version to the > > > next isn't great - it makes people more hesitant to upgrade. It's also > > > not a cost you're going to find all that quickly, and it's a really hard > > > to pin down cost. > > > > I'm +1 for enabling checksums by default, even with the performance > > penalties. > > > > As far as people upgrading, one advantage is existing pg_upgrade'd databases > > would not be affected. Only newly init'd clusters would get this setting. > > I think once we have better online enabling of checksums people can more > easily test the overhead on their workloads.
Yeah, definitely. If they have equivalent hardware they can easily do it now -- create a replica, turn off checksums on replica, compare. That is, assuming we turn them on by default :) But being able to turn them both on and off without a large downtime is obviously going to make experimentation a lot more reasonable. -- Magnus Hagander Me: https://www.hagander.net/ Work: https://www.redpill-linpro.com/
