[
https://issues.apache.org/jira/browse/CASSANDRA-1600?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13176291#comment-13176291
]
Jonathan Ellis commented on CASSANDRA-1600:
-------------------------------------------
What do we gain from "typedefing" List<IndexExpression> to FilterClause? (I
note this was part of Stu and my original attempts back in April but I don't
remember a good reason for that.)
{noformat}
+ /*
+ * XXX: If the range requested is a token range, we'll have to start
at the beginning (and stop at the end) of
+ * the indexed row unfortunately (which will be inefficient), because
we have not way to intuit the small
+ * possible key having a given token. A fix would be to actually store
the token along the key in the
+ * indexed row.
+ */
{noformat}
This is fine since there's no reason to be searching by token unless you're
doing an exhaustive scan, i.e. a m/r job.
{noformat}
+
rows.addAll(RangeSliceVerbHandler.executeLocally(command));
{noformat}
Another place the original patches failed... we should avoid this because it
means we're now allowing one range scan per thrift client instead of one per
read stage thread, and it bypasses the "drop hopeless requests" overcapacity
protection built in there. Look at SP.LocalReadRunnable for how to do this
safely. Simplest fix would be to just continue routing all range scans over
MessagingService.
Nit: I'd remove this comment
{code}
+ // Mostly just a typedef
{code}
since class definitions to hardcode a specific version of a generic type are an
antipattern, but this is necessary to "mix in" the CloseableIterator interface.
> Merge get_indexed_slices with get_range_slices
> ----------------------------------------------
>
> Key: CASSANDRA-1600
> URL: https://issues.apache.org/jira/browse/CASSANDRA-1600
> Project: Cassandra
> Issue Type: New Feature
> Components: API
> Reporter: Stu Hood
> Assignee: Sylvain Lebresne
> Fix For: 1.1
>
> Attachments:
> 0001-Add-optional-FilterClause-to-KeyRange-and-support-do-v2.patch,
> 0001-Add-optional-FilterClause-to-KeyRange-and-support-doin.txt,
> 0001-Add-optional-FilterClause-to-KeyRange-v3.patch,
> 0002-allow-get_range_slices-to-apply-filter-to-a-sequenti-v2.patch,
> 0002-allow-get_range_slices-to-apply-filter-to-a-sequential.txt,
> 0002-thrift-generated-code-changes-v3.patch,
> 0003-Allow-get_range_slices-to-apply-filter-to-a-sequenti-v3.patch,
> 0004-Update-cql-to-not-use-deprecated-index-scan-v3.patch
>
>
> From a comment on 1157:
> {quote}
> 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?
> {quote}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
