[
https://issues.apache.org/jira/browse/CASSANDRA-2894?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13073324#comment-13073324
]
Hudson commented on CASSANDRA-2894:
-----------------------------------
Integrated in Cassandra #989 (See
[https://builds.apache.org/job/Cassandra/989/])
add paging to get_count
patch by Byron Clark; reviewed by jbellis for CASSANDRA-2894
jbellis :
http://svn.apache.org/viewcvs.cgi/?root=Apache-SVN&view=rev&rev=1152545
Files :
* /cassandra/trunk/CHANGES.txt
* /cassandra/trunk/test/system/test_thrift_server.py
* /cassandra/trunk/src/java/org/apache/cassandra/thrift/CassandraServer.java
> 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: Byron Clark
> Priority: Minor
> Labels: lhf
> Fix For: 1.0
>
> Attachments: 2894-formatted.txt, 2894-with-batch-test.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: http://www.atlassian.com/software/jira
