You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cassandra.apache.org by "Vijay (JIRA)" <ji...@apache.org> on 2011/07/15 03:08:01 UTC
[jira] [Assigned] (CASSANDRA-2894) add paging to get_count
[ https://issues.apache.org/jira/browse/CASSANDRA-2894?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Vijay reassigned CASSANDRA-2894:
--------------------------------
Assignee: Vijay
> add paging to get_count
> -----------------------
>
> Key: CASSANDRA-2894
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2894
> Project: Cassandra
> Issue Type: Improvement
> Components: API
> Reporter: Jonathan Ellis
> Assignee: Vijay
> Priority: Minor
> Labels: lhf
> Fix For: 1.0
>
>
> 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: http://www.atlassian.com/software/jira