[
https://issues.apache.org/jira/browse/CASSANDRA-4476?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14233307#comment-14233307
]
Oded Peer commented on CASSANDRA-4476:
--------------------------------------
I am probably missing out something that is obvious to you.
{quote}The problem is that (1, 6), (2, 6) are never going to be returned if you
keep paging through the query in that fashion.{quote}
Why would you need to return these values if you specified a limit of 3 in your
query?
When doing a range query over a secondary index a view of the index data is
created in {{Collationcontroller.collectAllData()}} and iteration is done over
the intervalTree of that view. If I understand correctly the values in the
interval tree are the index values, not token, which ensures the iterator
results are ordered.
According to your comment paging is broken in this use case but the test I am
running isn't failing. Do you expect the test to fail?
> Support 2ndary index queries with only inequality clauses (LT, LTE, GT, GTE)
> ----------------------------------------------------------------------------
>
> Key: CASSANDRA-4476
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4476
> Project: Cassandra
> Issue Type: Improvement
> Components: API, Core
> Reporter: Sylvain Lebresne
> Assignee: Oded Peer
> Priority: Minor
> Labels: cql
> Fix For: 3.0
>
> Attachments: 4476-2.patch, 4476-3.patch, 4476-5.patch,
> cassandra-trunk-4476.patch
>
>
> Currently, a query that uses 2ndary indexes must have at least one EQ clause
> (on an indexed column). Given that indexed CFs are local (and use
> LocalPartitioner that order the row by the type of the indexed column), we
> should extend 2ndary indexes to allow querying indexed columns even when no
> EQ clause is provided.
> As far as I can tell, the main problem to solve for this is to update
> KeysSearcher.highestSelectivityPredicate(). I.e. how do we estimate the
> selectivity of non-EQ clauses? I note however that if we can do that estimate
> reasonably accurately, this might provide better performance even for index
> queries that both EQ and non-EQ clauses, because some non-EQ clauses may have
> a much better selectivity than EQ ones (say you index both the user country
> and birth date, for SELECT * FROM users WHERE country = 'US' AND birthdate >
> 'Jan 2009' AND birtdate < 'July 2009', you'd better use the birthdate index
> first).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
