cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Benedict (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CASSANDRA-8920) Optimise sequential overlap visitation
Date Thu, 19 Mar 2015 11:06:38 GMT

    [ https://issues.apache.org/jira/browse/CASSANDRA-8920?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14368868#comment-14368868
] 

Benedict commented on CASSANDRA-8920:
-------------------------------------

I've rebased this ontop of CASSANDRA-8988, which reduces the boilerplate.

> Optimise sequential overlap visitation
> --------------------------------------
>
>                 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)

Mime
View raw message