You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cassandra.apache.org by "Jonathan Ellis (JIRA)" <ji...@apache.org> on 2010/07/30 00:09:18 UTC

[jira] Created: (CASSANDRA-1339) add support for GT, GTE index expressions

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.0


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.


[jira] Commented: (CASSANDRA-1339) add support for GT, GTE index expressions

Posted by "Stu Hood (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/CASSANDRA-1339?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12919694#action_12919694 ] 

Stu Hood commented on CASSANDRA-1339:
-------------------------------------

Note that CASSANDRA-1472 already implements LT/LTE/GT/GTE locally, and can _very_ easily perform boolean operations between them.

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


[jira] Updated: (CASSANDRA-1339) add support for GT, GTE index expressions

Posted by "Stu Hood (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/CASSANDRA-1339?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stu Hood updated CASSANDRA-1339:
--------------------------------

    Component/s:     (was: Core)
                 API

Marking as API to get all secondary index issues together in one view.

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


[jira] Commented: (CASSANDRA-1339) add support for GT, GTE index expressions

Posted by "Stu Hood (JIRA)" <ji...@apache.org>.
    [ 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.


[jira] Commented: (CASSANDRA-1339) add support for GT, GTE index expressions

Posted by "Jonathan Ellis (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/CASSANDRA-1339?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12919897#action_12919897 ] 

Jonathan Ellis commented on CASSANDRA-1339:
-------------------------------------------

bq. I'm not sure why a KEYS index would need to query more nodes for GT/GTE/LT/LTE than it does for EQ

That's assuming that you want the results sorted in indexed column order.  It's hard to think of a use case for which token order would be useful for GT[E] queries.

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