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!
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 |