Re: data checksums - Mailing list pgsql-general

From Ron Johnson
Subject Re: data checksums
Date
Msg-id CANzqJaCXgvqqgev=SKaQvLu9RwjDfR_KXo_=Xpffm=jBkunvPg@mail.gmail.com
Whole thread Raw
In response to Re: data checksums  (Daniel Gustafsson <daniel@yesql.se>)
List pgsql-general
On Wed, Aug 7, 2024 at 3:41 AM Daniel Gustafsson <daniel@yesql.se> wrote:
> On 6 Aug 2024, at 18:29, Christophe Pettus <xof@thebuild.com> wrote:
>> On Aug 6, 2024, at 08:11, bruno vieira da silva <brunogiovs@gmail.com> wrote:

>> the pg doc
>> mentions a considerable performance penality, how considerable it is?
>
> That line is probably somewhat out of date at this point.  We haven't seen a significant slowdown in enabling them on any modern hardware.  I always turn them on, except on the type of filesystems/hardware mentioned above.

The last in-depth analysis of data checksums (and hint bits) overhead that I
can remember is from 2019:

  https://www.postgresql.org/message-id/20190330192543.GH4719%40development

A quote from that post:
"I have not investigated the exact reasons, but my hypothesis it's about
the amount of WAL generated during the initial CREATE INDEX (because it
probably ends up setting the hint bits), which puts additional pressure
on the storage."
 
Presuming that hypothesis is true: how often do "you" run CREATE INDEX (or VACUUM FULL or CLUSTER)?  I certainly don't run them very often.

--
Death to America, and butter sauce!
Iraq lobster...

pgsql-general by date:

Previous
From: Lok P
Date:
Subject: Re: Column type modification in big tables
Next
From: Costa Alexoglou
Date:
Subject: Vacuum full connection exhaustion