cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jeremy Hanna (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-9181) Improve index versus secondary index selection
Date Mon, 13 Apr 2015 21:12:15 GMT


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

View raw message