[
https://issues.apache.org/jira/browse/CASSANDRA-1339?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12919698#action_12919698
]
Stu Hood commented on CASSANDRA-1339:
-------------------------------------
Actually, I'm not sure why a KEYS index would need to query more nodes for
GT/GTE/LT/LTE than it does for EQ: locally, the operation is a merge of all
index values that match the predicate, and the merged values should be
completely consumed before querying the next node, right?
> add support for GT, GTE index expressions
> -----------------------------------------
>
> Key: CASSANDRA-1339
> URL: https://issues.apache.org/jira/browse/CASSANDRA-1339
> Project: Cassandra
> Issue Type: New Feature
> Components: Core
> Reporter: Jonathan Ellis
> Fix For: 0.7.1
>
>
> this will require hitting every node in the cluster and merging results,
> unlike with EQ.
> For instance, say we have the following index rows for some hypothetical
> column C1:
> Node 1, ('' - M]
> 4: A G K
> 5: B F J M
> Node 2, (M - '']
> 4: N P X
> 5: Q R T
> Because we store the index columns sorted in partitioner order, queries for
> C1=4 can scan first node 1, then if insufficient data is found, proceed to
> node 2. But for GT or GTE queries we have to scan everyone and merge.
> (Since we don't know what the next value after 4 is. So an alternative would
> be for each node to send back, along with the data for the first row, the row
> key that comes next. This would be very very messy.)
> Note that since we don't yet support range scans backwards, we can't support
> LT or LTE queries. The easiest workaround there would be to add a way to
> specify that you want to create an index on the comparator, reversed. This
> is also worth doing for optimizations within normal columns -- see
> CASSANDRA-1338.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
