[
https://issues.apache.org/jira/browse/CASSANDRA-749?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stu Hood updated CASSANDRA-749:
-------------------------------
Comment: was deleted
(was: > 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.
-
You can reply to this email to add a comment to the issue online.
