[ https://issues.apache.org/jira/browse/CASSANDRA-2698?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Benedict updated CASSANDRA-2698: -------------------------------- Attachment: trunk-2698.txt Hi Yuki, Sorry for the slight delay. I wanted to setup my development environment on my laptop after a hard disk failure before completing the changes, so I could configure ccm, intellij, etc. I opted in the end for the format [lb..ub] for range printing, as this seems to more neatly solve the problem of indicating the absolute min. There are some ugly complications with the other method around indicating a LB of 0 given the way EstimatedHistogram is defined ("defaults" to a LB of 1). It would probably result in -1s being needed again. > Instrument repair to be able to assess it's efficiency (precision) > ------------------------------------------------------------------ > > Key: CASSANDRA-2698 > URL: https://issues.apache.org/jira/browse/CASSANDRA-2698 > Project: Cassandra > Issue Type: Improvement > Reporter: Sylvain Lebresne > Assignee: Benedict > Priority: Minor > Labels: lhf > Attachments: nodetool_repair_and_cfhistogram.tar.gz, > patch_2698_v1.txt, patch.diff, patch-rebased.diff, patch.taketwo.alpha.diff, > patch.taketwo.forreview.diff, trunk-2698.txt > > > Some reports indicate that repair sometime transfer huge amounts of data. One > hypothesis is that the merkle tree precision may deteriorate too much at some > data size. To check this hypothesis, it would be reasonably to gather > statistic during the merkle tree building of how many rows each merkle tree > range account for (and the size that this represent). It is probably an > interesting statistic to have anyway. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira