[jira] [Issue Comment Deleted] (CASSANDRA-8920) Remove IntervalTree from maxPurgeableTimestamp calculation

["Benedict (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/CASSANDRA-8920?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Benedict updated CASSANDRA-8920:
--------------------------------
    Comment: was deleted

(was: I think for LCS we can still probably do better than we currently do. The IntervalTree is actually quite an expensive structure to query, and in this scenario I think we can do something much simpler: if we sort in ascending order by first _and_ ascending order by last,

I've uploaded my patch [here|https://github.com/belliottsmith/cassandra/tree/8920])

> 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
>            Assignee: Benedict
>            Priority: Minor
>             Fix For: 2.1.4
>
>         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)