[
https://issues.apache.org/jira/browse/CASSANDRA-4858?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13536084#comment-13536084
]
Sylvain Lebresne commented on CASSANDRA-4858:
---------------------------------------------
Is there a reason why this is limited to CL.ONE. Cause the problem is not
necessarily limited to CL.ONE. Typically, in the degenerated case where RF ==
number of nodes, only one command need to be created ever, even for CL.ALL.
More generally, as in the snippet of pseudo-code above, I think that as long as
the intersection of endpoints for the current range and of endpoints for the
next range is greater than what the consistency level require, then we can
merge both range in one command. I'm also not sure why we would limit this to
when RR is not true as long as the condition I've just described is true.
As as side note, there is a typo in IncludingExcludingBounds.cloneWithRight
(right is used twice).
> Coverage analysis for low-CL queries
> ------------------------------------
>
> Key: CASSANDRA-4858
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4858
> Project: Cassandra
> Issue Type: Improvement
> Components: Core
> Reporter: Jonathan Ellis
> Assignee: Vijay
> Fix For: 1.2.1
>
> Attachments: 0001-CASSANDRA-4858.patch
>
>
> There are many cases where getRangeSlice creates more
> RangeSliceCommand than it should, because it always creates one for each range
> returned by getRestrictedRange. Especially for CL.ONE this does not take
> the replication factor into account and is potentially pretty wasteful.
> A range slice at CL.ONE on a 3 node cluster with RF=3 should only
> ever create one RangeSliceCommand.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
