On 2/28/07, Gregory Stark <stark@enterprisedb.com> wrote:
> We reduced storage overhead using phantom command id by 8 bytes *per tuple*. I
> hardly think 8 bytes per page is much of a concern. You're already losing an
> average of 1/2 a tuple per page to rounding and that's a minimum of 16 bytes
> for the narrowest of tuples.
Again, it goes back to competent design. Save space here, waste it
there. SQL Server's bit-flipping technique is still *much* better
than wasting 1 byte for every 512.
> We've already seen wal CRC checking show up at the top of profiles.
Well, when you consider we're performing a CRC for every log record
rather than at the block level, like most other systems, I wouldn't be
that surprised. Don't try and use that example as a reason to kill
the checksum; it's a completely different use case.
> Do you really doubt that memcpy is faster than CRC32 checking? Especially when
> you're already doing memcpy anyways and the only overhead is the few unaligned
> bytes at the end and the 8 one-byte copies?
I'm saying the complexity and implementation of it is going to get you
a bit more than you think. If it didn't, you'd already have the thing
coded and would be proving me wrong with the patch rather than theory.I can code up a checksum version in an hour or
lessif you want to
give it a go.
--
Jonah H. Harris, Software Architect | phone: 732.331.1324
EnterpriseDB Corporation | fax: 732.331.1301
33 Wood Ave S, 3rd Floor | jharris@enterprisedb.com
Iselin, New Jersey 08830 | http://www.enterprisedb.com/
