Re: COMMIT NOWAIT Performance Option

"Gregory Stark" <stark(at)enterprisedb(dot)com> 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