[
https://issues.apache.org/jira/browse/CASSANDRA-7535?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14059380#comment-14059380
]
David Semeria commented on CASSANDRA-7535:
------------------------------------------
See [here|https://gist.github.com/hymanroth/cd9124b458870925afa2] for two
example tracings, both produced with 2.0.9 running vnodes. In the first tracing
there are around around 100 scans and in the second there are several thousand.
Querying the same node from another node running 2.0.4 consistently involved a
single scan.
I don't know if it's the same issue as
[CASSANDRA-6976|https://issues.apache.org/jira/browse/CASSANDRA-6976]
> 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)
