cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Semeria (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CASSANDRA-7535) Coverage analysis for range queries
Date Fri, 11 Jul 2014 22:05:06 GMT

    [ https://issues.apache.org/jira/browse/CASSANDRA-7535?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14059423#comment-14059423
] 

David Semeria commented on CASSANDRA-7535:
------------------------------------------

I forgot to mention that the issue starts to occur around 5 minutes after booting. This is
why I think the dynamic snitch might be playing a role, see the comments for [CASSANDRA-4858|https://issues.apache.org/jira/browse/CASSANDRA-4858].
When the issue occurs, the scans randomly vary between hundreds and thousands for each query,
but never one.

> 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)

Mime
View raw message