Re: Block-level CRC checks

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
Cc: "Jonah H(dot) Harris" <jonah(dot)harris(at)gmail(dot)com>, pgsql(at)mohawksoft(dot)com, Hannu Krosing <hannu(at)2ndquadrant(dot)com>, Decibel! <decibel(at)decibel(dot)org>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Block-level CRC checks
Date: 2008-10-01 16:05:06
Message-ID: 23740.1222877106@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Alvaro Herrera <alvherre(at)commandprompt(dot)com> writes:
> Tom Lane escribi:
>> No, not at all. Block-level checksums would be an order of magnitude
>> more expensive: they're on bigger chunks of data and they'd be done more
>> often.

> More often? My intention is that they are checked when the buffer is
> read in, and calculated/stored when the buffer is written out.

Right. My point is that the volume of data involved is more than the
WAL traffic. Example: you update one tuple on a page, your WAL record
is that tuple, but you had to checksum the whole page when you read it
in and you'll have to do it again when you write it out. Not to mention
that in a read-mostly query mix there's not much WAL traffic at all,
but plenty of page reading (and maybe some writing too, if hint bit
updates happen).

"Order of magnitude" might be an overstatement, but I don't believe
for a moment that the cost will be negligible. That's why I'm thinking
about something cheaper than a full-blown CRC calculation.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Hitoshi Harada 2008-10-01 16:05:57 Re: Common Table Expressions (WITH RECURSIVE) patch
Previous Message Florian Weimer 2008-10-01 16:04:06 Re: Block-level CRC checks