cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Benedict (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-8920) Optimise sequential overlap visitation
Date Tue, 31 Mar 2015 13:32:53 GMT


Benedict commented on CASSANDRA-8920:

You're probably right; algorithmically it is overshadowed by the sorting for the moment as
well. Pushed a version that removes this.

> Optimise sequential overlap visitation
> --------------------------------------
>                 Key: CASSANDRA-8920
>                 URL:
>             Project: Cassandra
>          Issue Type: Improvement
>          Components: Core
>            Reporter: Benedict
>            Assignee: Benedict
>            Priority: Minor
>             Fix For: 3.0
>         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

View raw message