[
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)
