Re: data_checksums enabled by default (was: Move --data-checksums to common options in initdb --help)
Andres Freund <andres@anarazel.de>
From: Andres Freund <andres@anarazel.de>
To: Michael Banck <michael.banck@credativ.de>
Cc: Stephen Frost <sfrost@snowman.net>, Michael Paquier <michael@paquier.xyz>, PostgreSQL Development <pgsql-hackers@postgresql.org>
Date: 2021-01-06T03:35:43Z
Lists: 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
Commits
-
Promote --data-checksums to the common set of options in initdb --help
- bc08f7971c03 14.0 landed