[
https://issues.apache.org/jira/browse/CASSANDRA-7535?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14059059#comment-14059059
]
David Semeria commented on CASSANDRA-7535:
------------------------------------------
Sorry Brandon, I misinterpreted your reply. What I meant to say was to check
2.0.9 which I believe is the current stable version. I don't know if vnodes are
the culprit because I don't have a simple way of checking. I'm guessing that a
vnode range is the same as a normal range, except there are more of them.
Just to emphasize the point, running a range query from DC1 with CL.ALL was 10x
quicker than running the same query with CL.LOCAL_ONE in DC2. It's clearly an
issue with the query planner in 2.0.9
> Coverage analysis for range queries
> -----------------------------------
>
> Key: CASSANDRA-7535
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7535
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Reporter: David Semeria
> Assignee: Tyler Hobbs
> Fix For: 2.0.10
>
>
> This is a regression related to
> [CASSANDRA-4858|https://issues.apache.org/jira/browse/CASSANDRA-4858]
> Range queries are taking orders of magnitude more time to complete than
> before because the query planner is frequently unable to calculate the
> correct intersection of contiguous ranges for a given node.
> For example, SELECT * FROM TBL should result in exactly one scan at CL.ONE
> when RF = #nodes when in fact it can result in several hundred scans
> (sometimes thousands). The problem is exasperated with vnodes.
> The regression occurred at some point between 2.0.4 (which works fine) and
> 2.0.9.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
