← Back to team overview

percona-discussion team mailing list archive

Re: simple optimizations

 

Hi Mark, Vadim,

On 28/04/2009, at 10:58 PM, MARK CALLAGHAN wrote:
Have you seen this bug report?
http://bugs.mysql.com/bug.php?id=19975

Also, have you done any experiments with the page checksum method for
InnoDB to make it faster or to change the algorithm and I realize that
changing the algorithm has a huge impact on deployed servers. Once you
begin doing a lot of IO on fast SSD systems, you will burn a lot of
CPU time doing checksum validation.


Note in buf/buf0buf.c that the old checksum is still used as well as the new.
Would it be possible to remove the old, at least?

And what is actually going on in include/ut0rnd.ic with the homegrown foo?
ut_fold_binary() is the function used for generating the checksum.
What kind of bit errors does the homegrown stuff detect, how does it hold up to say CRC in terms of catching problems, and computational complexity/speed? Look, if we were to change algorithms... CRCs can be optimised, and there are I believe also newer algorithms that can be even less computationally intensive.

But there's an additional issue with the whole checksum foo. The checksum is right next to the data, and while CRCs are decent at detecting corruption, the proximity can also hide some occurrances. ZFS has the nifty trick of storing checksums separately, and I think that's quite brilliant. Not saying it's easy to do for InnoDB or even if it's desirable - just want to put it out there so we can discuss.


Cheers,
Arjen.
--
Arjen Lentz, Director @ Open Query (http://openquery.com)
Affordable Training and ProActive Support for MySQL & related technologies

Follow our blog at http://openquery.com/blog/
OurDelta: free enhanced builds for MySQL @ http://ourdelta.org




Follow ups

References