[
https://issues.apache.org/jira/browse/CASSANDRA-8906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14347159#comment-14347159
]
Jonathan Ellis edited comment on CASSANDRA-8906 at 3/4/15 5:08 PM:
-------------------------------------------------------------------
Doesn't that mean you still need to compare on min/max instead of on the
partition key? (So total number of comparisons is the same.)
was (Author: jbellis):
Doesn't that mean you still need to compare on min/max instead of on the
partition key?
> Experiment with optimizing partition merging when we can prove that some
> sources don't overlap
> ----------------------------------------------------------------------------------------------
>
> Key: CASSANDRA-8906
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8906
> Project: Cassandra
> Issue Type: Improvement
> Reporter: Sylvain Lebresne
>
> When we merge a partition from two sources and it turns out that those 2
> sources don't overlap for that partition, we still end up doing one
> comparison by row in the first source. However, if we can prove that the 2
> sources don't overlap, for example by using the sstable min/max clustering
> values that we store, we could speed this up. Note that it practice it's
> little bit more hairy because we need to deal with N sources, but that's
> probably not too hard either.
> I'll note that using the sstable min/max clustering values is not terribly
> precise. We could do better if we were to push the same reasoning inside the
> merge iterator, by for instance using the sstable per-partition index, which
> can in theory tell use things like "don't bother comparing rows until the end
> of this row block". This is quite a bit more involved though so maybe note
> worth the complexity.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
