[ https://issues.apache.org/jira/browse/CASSANDRA-8920?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Benedict updated CASSANDRA-8920: -------------------------------- Attachment: 8920.txt > Remove IntervalTree from maxPurgeableTimestamp calculation > ---------------------------------------------------------- > > Key: CASSANDRA-8920 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8920 > Project: Cassandra > Issue Type: Improvement > Components: Core > Reporter: Benedict > Priority: Minor > Attachments: 8920.txt > > > The IntervalTree only maps partition keys. Since a majority of users deploy a > hashed partitioner the work is mostly wasted, since they will be evenly > distributed across the full token range owned by the node - and in some cases > it is a significant amount of work. We can perform a corroboration against > the file bounds if we get a BF match as a sanity check if we like, but > performing an IntervalTree search is significantly more expensive (esp. once > murmur hash calculation memoization goes mainstream). > In LCS, the keys are bounded, to it might appear that it would help, but in > this scenario we only compact against like bounds, so again it is not helpful. > With a ByteOrderedPartitioner it could potentially be of use, but this is > sufficiently rare to not optimise for IMO. -- This message was sent by Atlassian JIRA (v6.3.4#6332)