[ https://issues.apache.org/jira/browse/CASSANDRA-2894?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jonathan Ellis resolved CASSANDRA-2894. --------------------------------------- Resolution: Fixed Reviewer: jbellis Assignee: Byron Clark committed, thanks! created CASSANDRA-2977 for the multiget case, for completeness; however, I incline towards option 1 ("do nothing"). > 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