From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Andreas Joseph Krogh <andreas(at)visena(dot)com> |
Cc: | pgsql-general(at)lists(dot)postgresql(dot)org |
Subject: | Re: Sv: Re: Sv: Re: Sv: Re: Sv: Re: data-checksums |
Date: | 2018-01-10 01:55:25 |
Message-ID: | 20180110015525.orxpcm7qlo7nt7ro@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On 2018-01-10 01:31:58 +0100, Andreas Joseph Krogh wrote:
> På onsdag 10. januar 2018 kl. 01:01:26, skrev Andres Freund <andres(at)anarazel(dot)de
> <mailto:andres(at)anarazel(dot)de>>:
> On 2018-01-10 00:25:08 +0100, Andreas Joseph Krogh wrote:
> > But SIMD-instructions are also HW-accellerated by modern CPUs IIUC?
>
> Sure. Still measurable, but even if weren't, it's irrelevant given my
> primary point:
>
> > The checksum computations have some impact, but if there's bigger impact
> > it's much more likely to be related to the fact that some hint bit
> > writes to a page now needs to be WAL logged.
>
> which isn't mitigated by SIMD / hardware CRC / whatnot.
>
> Aha, so enabling CRC causes hint-bits to be written causing extra WAL-logging,
> which woudn't be the case without CRC enabled?
> Thanks for pointing that out.
Well, enabling checksums enables that. CRCs don't play a role for data
checksums. CRCs are a specific class of checksums, a specific one of
those is used in our WAL logging, but the data checksum algorithm isn't
in that class.
Greetings,
Andres Freund
From | Date | Subject | |
---|---|---|---|
Next Message | Glauco Torres | 2018-01-10 11:49:01 | Segmentation fault with core dump |
Previous Message | Stephen Frost | 2018-01-10 01:51:17 | Re: Sv: Re: Sv: Re: Sv: Re: Sv: Re: data-checksums |