[
https://issues.apache.org/jira/browse/CASSANDRA-7535?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tyler Hobbs updated CASSANDRA-7535:
-----------------------------------
Attachment: 7535.txt
Post-6465, it was much more likely for all scores to be 0. In this case,
{{maxMerged < maxL1 + maxL2}} is false, so the ranges were not merged. The
7535.txt patch makes that a {{<=}} check to handle the all-zeroes case.
Besides that, it seems like we should give some additional preference to
merging ranges, given the overhead of each range request. This is especially
true for vnodes. So, I've also added a {{RANGE_MERGING_PREFERENCE}} of 1.5,
meaning the merged score must be that much worse than the separate scores for
the ranges to remain split. I don't believe there's a lot of value in making
this configurable, so I've left it hard-coded for now.
There's also a [branch|https://github.com/thobbs/cassandra/tree/CASSANDRA-7535]
with the changes.
> 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
>
> Attachments: 7535.txt
>
>
> 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)
