[
https://issues.apache.org/jira/browse/CASSANDRA-9181?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14493102#comment-14493102
]
Jeremy Hanna commented on CASSANDRA-9181:
-----------------------------------------
This appears to be a regression as it should already use the partition key
first. To give some detail on how we observed the behavior, we were using
interactive query tracing in DevCenter which is hardcoded to use CL.ONE right
now. The query trace with only the partition key shows the expected behavior
of contacting a replica and fulfilling the query. The query trace with the
partition key and the secondary index contacts multiple hosts for coverage.
I'll see if I can get the output for inclusion on the ticket.
> Improve index versus secondary index selection
> ----------------------------------------------
>
> Key: CASSANDRA-9181
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9181
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Reporter: Jeremy Hanna
> Labels: 2i
> Fix For: 3.0
>
>
> There is a special case for secondary indexes if you always supply the
> partition key. For example, if you have a family with ID "a456" which has 6
> family members and I have a secondary index on first name. Currently, if I
> do a query like this "select * from families where id = 'a456' and firstname
> = 'alowishus';" you can see from a query trace, that it will first scan the
> entire cluster based on the firstname, then look for the key within that.
> If it's not terribly invasive, I think this would be a valid use case to
> narrow down the results by key first.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
