[
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
