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? http://www.postgresql.org/docs/faq
