cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Byron Clark (JIRA)" <>
Subject [jira] [Updated] (CASSANDRA-2894) add paging to get_count
Date Sun, 31 Jul 2011 03:34:09 GMT


Byron Clark updated CASSANDRA-2894:

    Attachment: 2894-with-test.txt

[^2894-with-test.txt] incorporates Jonathan's changes and adds a system test to exercise paging.
The bad news is that the test takes over a minute to run on my machine.

This patch also handles (and tests for) the case where count is set to something other than
Integer.MAX_VALUE on the SliceRange.

> add paging to get_count
> -----------------------
>                 Key: CASSANDRA-2894
>                 URL:
>             Project: Cassandra
>          Issue Type: Improvement
>          Components: API
>            Reporter: Jonathan Ellis
>            Priority: Minor
>              Labels: lhf
>             Fix For: 1.0
>         Attachments: 2894-formatted.txt, 2894-with-test.txt, CASSANDRA-2894.patch
> It is non-intuitive that get_count materializes the entire slice-to-count on the coordinator
node (to perform read repair and > CL.ONE consistency).  Even experienced users have been
known to cause memory problems by requesting large counts.
> The user cannot page the count himself, because you need a start and stop column to do
that, and get_count only returns an integer.
> So the best fix is for us to do the paging under the hood, in CassandraServer.  Add a
limit to the slicepredicate they specify, and page through it.
> We could add a global setting for count_slice_size, and document that counts of more
columns than that will have higher latency (because they make multiple calls through StorageProxy
for the pages).

This message is automatically generated by JIRA.
For more information on JIRA, see:


View raw message