[
https://issues.apache.org/jira/browse/CASSANDRA-749?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12857541#action_12857541
]
Stu Hood commented on CASSANDRA-749:
------------------------------------
> If the property is NOT the original, base row key, then not matter what kind
> of index you have, you
> need to read all the results to sort in the desired order
I think we agree that we would never want to allow this. Instead, for an index
read with the non-local index, I would propose that the order _must_ be defined
beforehand. If, for instance, you wanted to do an index read in base row key
order, then you would need to define an index with a compound key of
'basevalue|basekey', so that each basevalue (presumably low cardinality) would
be sorted by the basekey.
For range queries over a few basevalues, there would be some merging involved,
but it would _not_ need a sort, and it wouldn't necessarily involve the entire
cluster. For instance, for a range query for index values between 1969 and
1970, you would have two basevalues to consider, and so you would want to
perform a merge of the (pre-sorted) basekeys for 1969 and 1970.
EDIT: sorry, I facepalmed after writing this comment, and deleted it briefly:
the compound key would be 'basevalue|basekey', which changes a few things.
> Secondary indices for column families
> -------------------------------------
>
> Key: CASSANDRA-749
> URL: https://issues.apache.org/jira/browse/CASSANDRA-749
> Project: Cassandra
> Issue Type: New Feature
> Components: Core
> Reporter: Gary Dusbabek
> Assignee: Gary Dusbabek
> Priority: Minor
> Fix For: 0.8
>
> Attachments: 0001-simple-secondary-indices.patch,
> views-discussion-2.txt, views-discussion.txt
>
>
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
