Re: Block-level CRC checks

From: Gregory Stark <stark(at)enterprisedb(dot)com>
To: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
Cc: Martijn van Oosterhout <kleptog(at)svana(dot)org>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Greg Stark <greg(dot)stark(at)enterprisedb(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Block-level CRC checks
Date: 2008-11-12 20:38:33
Message-ID: 87vdusu1bq.fsf@oxford.xeocode.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Alvaro Herrera <alvherre(at)commandprompt(dot)com> writes:

> The other thing that maybe you didn't notice is that lp_flags are 2
> bits, not a full byte. A byte-at-a-time CRC calculation is no help
> there.

I think we're talking past each other. Martin and I are talking about doing
something like:

for (...)
...
crc(word including hint bits)
...
for (each line pointer)
crc-negated(word & LP_DEAD<<15)

Because CRC is a cyclic checksum it's possible to add or remove bits
incrementally. This only works if the data is already copied to someplace so
you can be sure nobody will set or clear the bits behind your back. But when
you're reading the data back in you don't have to worry about that.

I'm a bit surprised to hear our CRC implementation is a bytewise loop. I
thought it was much faster to process CRC checks word-wise.

--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Ask me about EnterpriseDB's PostGIS support!

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2008-11-12 21:09:19 Re: [GENERAL] Very slow queries w/ NOT IN preparation (seems like a bug, test case)
Previous Message Alvaro Herrera 2008-11-12 20:24:41 Re: Block-level CRC checks