[ 
https://issues.apache.org/jira/browse/CASSANDRA-4476?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14176736#comment-14176736
 ] 

Sylvain Lebresne commented on CASSANDRA-4476:
---------------------------------------------

Good question. This ticket was only ever meant to deal with {{LT}}, {{LTE}}, 
{{GTE}} and {{GT}} so let's leave it to that for this ticket (I've made the 
title more precise). Regarding {{IN}}, it could be supported, but for the sake 
of doing one thing at a time, it's probably better to leave it a as follow up 
of this ticket. For {{NEQ}}, I see no way to do it in even a vaguely efficient 
way (at least with the current indexing scheme) so I don't think there is any 
plan to ever support it (but even if someone has a brilliant idea how to do it, 
it's definitively a separate issue). 

> 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
>            Priority: Minor
>              Labels: cql
>             Fix For: 2.1.2
>
>
> 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)

Reply via email to