Skip site navigation (1) Skip section navigation (2)

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 (view raw or flat)
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

pgsql-hackers by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group