On Fri, Jan 8, 2021 at 4:57 PM Bruce Momjian <bruce@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
tunedto have a database that's usable in an even halfway busy setup. That's unavoidable in some cases, but it's a
significantcost across use cases.
> > >
> > > Increasing the overhead in the default config from one version to the next isn't great - it makes people more
hesitantto 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/
