[jira] [Updated] (CASSANDRA-8920) Optimise sequential overlap visitation for checking tombstone retention in compaction

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

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

Wei Deng updated CASSANDRA-8920:
--------------------------------
    Labels: compaction lcs performance  (was: performance)

> Optimise sequential overlap visitation for checking tombstone retention in compaction
> -------------------------------------------------------------------------------------
>
>                 Key: CASSANDRA-8920
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-8920
>             Project: Cassandra
>          Issue Type: Improvement
>            Reporter: Benedict
>            Assignee: Benedict
>            Priority: Minor
>              Labels: compaction, lcs, performance
>             Fix For: 2.2.0 beta 1
>
>         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)