[
https://issues.apache.org/jira/browse/CASSANDRA-1157?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12906229#action_12906229
]
Stu Hood commented on CASSANDRA-1157:
-------------------------------------
Sorry to chime in so late (and probably on the wrong ticket), but it doesn't
look like get_indexed_slices needs to be a separate method from
get_range_slices.
IndexClause only has a start key for get_indexed_slices, but it would seem that
the reasoning behind using 'KeyRange' for get_range_slices applies there as
well, since if you know the range you care about in the primary index, you
don't want to continue scanning until you exhaust 'count' (or the cluster).
Since it would appear that get_indexed_slices would benefit from a KeyRange,
why not smash get_(range|indexed)_slices together, and make IndexClause an
optional field on KeyRange?
> add support for multiple indexexpressions
> -----------------------------------------
>
> Key: CASSANDRA-1157
> URL: https://issues.apache.org/jira/browse/CASSANDRA-1157
> Project: Cassandra
> Issue Type: Sub-task
> Reporter: Jonathan Ellis
> Assignee: Jonathan Ellis
> Fix For: 0.7 beta 1
>
> Attachments: 1157-v2.txt, 1157.txt,
> 1157_thrift_validation_fix_w_tests.txt
>
>
> we should:
> - use the statistics from CASSANDRA-1155 to figure out which index has the
> highest selectivity, and start with that
> - if other indexes have high selectivity (average number of columns in an
> index row is less than 1% of total in that CF), we should do a merge join
> - otherwise, just loop the results from the first and reject un-satisfied
> expressions
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
