# pt-table-checksum questions about algorithm

**URL:** <https://forums.percona.com/t/pt-table-checksum-questions-about-algorithm/3357>\
**Category:** Percona Toolkit\
**Created:** [March 22, 2014, 3:39pm UTC](https://forums.percona.com/t/pt-table-checksum-questions-about-algorithm/3357 "2014-03-22T15:39:46Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**Author:** ![neuen](https://avatars.discourse-cdn.com/v4/letter/n/b38774/32.png) [@neuen](https://forums.percona.com/u/neuen)\
**Post date:** [March 22, 2014, 3:39pm UTC](https://forums.percona.com/t/pt-table-checksum-questions-about-algorithm/3357/1 "2014-03-22T15:39:46Z")

</div>

Hi,

excuse me for my bad Perl knowledge, I was not able to read and understand pt-table-checksum code thoroughly so my questions might be quite simple. Here they are.

1. It issues $ub\_sql query to get {upper} boundary for current chunk and {next\_lower} boundary for next chunk if available. Does it check replicas have no data between {upper} and {next\_lower}?

2. Issuing $ub\_sql and then $checksum\_dml partially reads same data twice (LIMIT with offset has to pass that many rows). Considering master server it is run on is often the main production server and is quite IO busy/bound it is either resource intensive or time consuming (or both). Why cannot it issue $checksum\_dml only but with $ub\_sql LIMIT instead of WHERE boundaries, log max boundary to percona table and check it is the same across all replicas? This will change O(N) complexity for running $ub\_sql to O(1) complexity for running one row select from percona table.

I mean query like this (for simplicity I assume index single column):

REPLACE INTO `percona`.`checksums` (db, tbl, chunk, chunk\_index, lower\_boundary, upper\_boundary, this\_cnt, this\_crc)  
SELECT ‘schema’, ‘table’, ‘chunk’, ‘chunk\_index’, ‘lower\_boundary’,  
MAX(`index_field`) AS upper\_boundary,  
COUNT(\*) AS cnt,  
COALESCE(LOWER(CONV(BIT\_XOR(CAST(CRC32(CONCAT\_WS(’ #', `field1`, …, `fieldN`, CONCAT(ISNULL(`field1`), …, ISNULL(`fieldN`)))) AS UNSIGNED)), 10, 16)), 0) AS crc  
FROM `schema`.`table` FORCE INDEX(`chunk_index`)  
WHERE `index_field`\>=:upper\_boundary\_of\_previous\_chunk:  
ORDER BY `index_field`  
LIMIT ?  
/_checksum chunk_/

At least one row which satisfies WHERE `index_field`=:upper\_boundary\_of\_previous\_chunk: will be read twice this way. This won’t spoil checksum results but is unnecessary overhead. I’m quite sure this can be avoided with something like MAX(CASE … END) however I don’t want to go that far now.

Thanks for the answers in advance.