cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Tyler Hobbs (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-1337) parallelize fetching rows for low-cardinality indexes
Date Wed, 02 Oct 2013 19:15:45 GMT


Tyler Hobbs commented on CASSANDRA-1337:

bq. Pushed some super minor cleanup to

In your OCD commit, replacing the haveSufficientRows/break behavior with a return means that
we won't wait on the repair futures, which I believe is incorrect.

bq. Question left in my mind is, do we want to shoot for exactly enough concurrent requests,
on average? Would imply that half the time we need to do an extra round. ISTM we probably
want to give ourselves a margin of error.

True.  Perhaps we should decrease our estimate of rows per range by, say, 10%, and use Math.ceil()
instead of Math.round() for the concurrency factor calculation.

> parallelize fetching rows for low-cardinality indexes
> -----------------------------------------------------
>                 Key: CASSANDRA-1337
>                 URL:
>             Project: Cassandra
>          Issue Type: Improvement
>            Reporter: Jonathan Ellis
>            Assignee: Tyler Hobbs
>            Priority: Minor
>             Fix For: 2.1
>         Attachments: 0001-Concurrent-range-and-2ary-index-subqueries.patch, 1137-bugfix.patch,
1337.patch, 1337-v4.patch, ASF.LICENSE.NOT.GRANTED--0001-CASSANDRA-1337-scan-concurrently-depending-on-num-rows.txt,
>   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 was sent by Atlassian JIRA

View raw message