cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Aleksey Yeschenko (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CASSANDRA-10214) Enable index selection to be overridden on a per query basis
Date Fri, 28 Aug 2015 14:22:45 GMT

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

Aleksey Yeschenko commented on CASSANDRA-10214:
-----------------------------------------------

What Sylvain said.

We do not have a query planner, and the heuristics we have, are not up to the task. Moreover,
with the introduction of multiple indexes per column, I don't think there even are good enough
potential heuristics. Imagine having several indexes on the identical columns, all backed
by different CUSTOM implementations - something using MVs under the hood, something using
Solr, something using a method that's close to our native 2i, but includes the original partition
key in its tables. We cannot make a good choice here.

Imagine, purely hypothetically, that someone decides to implement, for example, a graph database
on top of Cassandra, and they *do* implement a query planner (out of necessity), and they
do use a bunch of different indexes under the hood. To those hypothetical people it would
be beneficial to be able to explicitly set the index to be used.

Even without that, though, it's nice to have. And {{USING NO INDEX}}, too.

> Enable index selection to be overridden on a per query basis
> ------------------------------------------------------------
>
>                 Key: CASSANDRA-10214
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-10214
>             Project: Cassandra
>          Issue Type: New Feature
>            Reporter: Sam Tunnicliffe
>             Fix For: 3.x
>
>
> (Broken out of CASSANDRA-10124)
> We could add a {{USING INDEX <indexname>}} clause to {{SELECT}} syntax to force
the choice of index and bypass the usual index selection mechanism.
> {code}
> CREATE TABLE ks.t1(k int, v1 int, v2 int, PRIMARY KEY (k));
> CREATE INDEX v1_idx ON ks.t1(v1);
> CREATE INDEX v2_idx ON ks.t1(v2);
> CREATE CUSTOM INDEX v1_v2_idx ON ks.t1(v1, v2) USING 'com.foo.bar.CustomMultiColumnIndex';
> # Override internal index selection mechanism
> SELECT * FROM ks.t1 WHERE v1=0 AND v2=0 USING INDEX v1_idx;
> SELECT * FROM ks.t1 WHERE v1=0 AND v2=0 USING INDEX v2_idx;
> SELECT * FROM ks.t1 WHERE v1=0 AND v2=0 USING INDEX v1_v2_idx;
> {code}
> This is in some ways similar to [index hinting|http://docs.oracle.com/cd/B19306_01/server.102/b14211/hintsref.htm#CHDJDIAH]
in Oracle. 
> edit: fixed typo's (missing INDEX in the USING clauses)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message