"Gregory Stark" <[EMAIL PROTECTED]> writes: > We've already seen wal CRC checking show up at the top of profiles. > > 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?
Well color me surprised, writev is not nearly so much faster than CRC as I had expected: lseek+write syscall overhead: 7.95 us CRC32 32.54 us writev 26.56 us The reason there's lseek overhead in there is because I had it seek back to the same block repeatedly to (hopefully) avoid any i/o. It seems to have worked as I find it hard to believe these numbers could be so low if there's any i/o being included. I think part of the reason writev is slow is because I'm including the time it took to set up the iovec array. That's 64 word copies write there. And then writev has to read those 64 words back and do 64 extra branches and so on... This is on an Intel T2500 (2Ghz). There is a side issue that tagging each sector is 100% guaranteed to detect torn pages whereas checksums still have a chance of missing them. But usually the scenario where that comes into play is where you have many checksum failures and are ignoring them assuming they never fail. In the case of torn pages there'll only be one torn page and we're going to scream bloody murder if we see it so I don't think that's a big issue. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com ---------------------------(end of broadcast)--------------------------- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq