Re: data_checksums enabled by default (was: Move --data-checksums to common options in initdb --help) - Mailing list pgsql-hackers

From Andres Freund
Subject Re: data_checksums enabled by default (was: Move --data-checksums to common options in initdb --help)
Date
Msg-id 20210106033543.mmjrukti5mnfavaz@alap3.anarazel.de
Whole thread Raw
In response to data_checksums enabled by default (was: Move --data-checksums to common options in initdb --help)  (Michael Banck <michael.banck@credativ.de>)
Responses Re: data_checksums enabled by default (was: Move --data-checksums to common options in initdb --help)
List pgsql-hackers
Hi,

On 2021-01-04 19:11:43 +0100, Michael Banck wrote:
> Am Samstag, den 02.01.2021, 10:47 -0500 schrieb Stephen Frost:
> > * Michael Paquier (michael@paquier.xyz) wrote:
> > > On Fri, Jan 01, 2021 at 08:34:34PM +0100, Michael Banck wrote:
> > > > I think enough people use data checksums these days that it warrants to
> > > > be moved into the "normal part", like in the attached.
> > > 
> > > +1.  Let's see first what others think about this change.
> > 
> > I agree with this, but I'd also like to propose, again, as has been
> > discussed a few times, making it the default too.

FWIW, I am quite doubtful we're there performance-wise. Besides the WAL
logging overhead, the copy we do via PageSetChecksumCopy() shows up
quite significantly in profiles here. Together with the checksums
computation that's *halfing* write throughput on fast drives in my aio
branch.


> This looks much better from the WAL size perspective, there's now almost
> no additional WAL. However, that is because pgbench doesn't do TOAST, so
> in a real-world example it might still be quite larger. Also, the vacuum
> runtime is still 15x longer.

That's obviously an issue.


> So maybe we should switch on wal_compression if we enable data checksums
> by default.

It unfortunately also hurts other workloads. If we moved towards a saner
compression algorithm that'd perhaps not be an issue anymore...

Greetings,

Andres Freund



pgsql-hackers by date:

Previous
From: "movead.li@highgo.ca"
Date:
Subject: RE: Wrong statistics for size of XLOG_SWITCH during pg_waldump.
Next
From: Amit Kapila
Date:
Subject: Re: [HACKERS] logical decoding of two-phase transactions