cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sylvain Lebresne (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CASSANDRA-4476) Support 2ndary index queries with only inequality clauses (LT, LTE, GT, GTE)
Date Mon, 20 Oct 2014 09:08:36 GMT

    [ 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)

Mime
View raw message