On 2/28/07, Gregory Stark <[EMAIL PROTECTED]> 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 less if 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 | [EMAIL PROTECTED]
Iselin, New Jersey 08830 | http://www.enterprisedb.com/
---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?