[
https://issues.apache.org/jira/browse/CASSANDRA-4476?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14231775#comment-14231775
]
Benjamin Lerer commented on CASSANDRA-4476:
-------------------------------------------
Here are my review feedback on the latest patch:
* I think that you should use {{isRange}} or {{isSlice}} instead of
{{isRelationalOrderOperator}} as it is clearer.
* The name of test class: {{SecondaryIndexNonEqTest}} is misleading.
{{CONTAINS}} an {{CONTAINS KEY}} operator are also non eq tests.
* In {{getRelationalOrderEstimatedSize}} I do not understand why you do not
return 0 if {{estimatedKeysForRange}} return 0. Could you explain?
* Instead of doing some dangerous casting in
{{getRelationalOrderEstimatedSize}}, you should change the type from
{{bestMeanCount}} from int to long.
* In {{computeNext}} I do not understand why you do not check for stale data
for range queries? Could you explain?
* I think it would be nicer to have also an iterator for EQ and use
polymorphism instead of if else.
* The close method of the {{AbstractScanIterator}} returned by
{{getSequentialIterator}} should be called from the close method.
* The Unit tests are only covering a subset of the possible queries. Could you
add more (a > 3 and a <4, a < 3 and a > 4 ...)
* When testing for InvalidRequestException you should use
{{assertInvalidMessage}}
> 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, 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)
