[
https://issues.apache.org/jira/browse/CASSANDRA-1337?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13424071#comment-13424071
]
David Alves edited comment on CASSANDRA-1337 at 7/27/12 7:07 PM:
-----------------------------------------------------------------
patch that addresses the bugs raised by sylvain. (StoragProxyTest and
cql_test.py both pass) namely:
- local path counts as one less handler
- enough check moved out of the remote branch
- estimatedKeysPerRange take into account replication factor
- columns.maxIsColumns sets concurrency to 1
still working on the dtest that proves (or disproves that this works) but both
StorageProxyTest and the regression test created by Sylvain pass
I'd like to move the rest of the issues raised by sylvain to another ticket.
was (Author: dr-alves):
patch that addresses the bugs raised by sylvain. (StoragProxyTest and
cql_test.py both pass) namely:
- local path counts as one less handler
- enough check moven out of the remote branch
- estimatedKeysPerRange take into account replication factor
- columns.maxIsColumns sets concurrency to 1
still working on the dtest that proves (or disproves that this works)
I'd like to move the rest of the issues raised by sylvain to another ticket.
> parallelize fetching rows for low-cardinality indexes
> -----------------------------------------------------
>
> Key: CASSANDRA-1337
> URL: https://issues.apache.org/jira/browse/CASSANDRA-1337
> Project: Cassandra
> Issue Type: Improvement
> Reporter: Jonathan Ellis
> Assignee: David Alves
> Fix For: 1.2
>
> Attachments:
> 0001-CASSANDRA-1337-scan-concurrently-depending-on-num-rows.txt,
> 1137-bugfix.patch, CASSANDRA-1337.patch
>
> Original Estimate: 8h
> Remaining Estimate: 8h
>
> currently, we read the indexed rows from the first node (in partitioner
> order); if that does not have enough matching rows, we read the rows from the
> next, and so forth.
> we should use the statistics fom CASSANDRA-1155 to query multiple nodes in
> parallel, such that we have a high chance of getting enough rows w/o having
> to do another round of queries (but, if our estimate is incorrect, we do need
> to loop and do more rounds until we have enough data or we have fetched from
> each node).
--
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
