[jira] [Comment Edited] (CASSANDRA-8483) Support streaming results

["Benedict (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/CASSANDRA-8483?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14246735#comment-14246735 ] 

Benedict edited comment on CASSANDRA-8483 at 12/15/14 3:25 PM:
---------------------------------------------------------------

bq. or even if the effort is really worth the trouble

Well, streaming reads comes up regularly as a topic, and it makes a lot of sense for keeping GC requirements constant regardless of workload. However if we decide we don't want to introduce them in future this ticket is definitely superfluous. I think we would be mistaken not to target a world where all workloads require a static amount of resources to service, to reduce total heap requirements and just as importantly to avoid hunting through heap dumps just to tell the user there are problems with their data model. But that's just me, and I'll let others chime in if they think it's a terrible idea.


was (Author: benedict):
bq. or even if the effort is really worth the trouble

Well, streaming reads comes up regularly as a topic, and it makes a lot of sense for keeping GC requirements constant regardless of workload. However if we decide we don't want to introduce them in future this ticket is definitely superfluous. I think we would be mistaken not to target a world where all workloads require a static amount of resources to service, to reduce total heap requirements and just as importantly to avoid hunting through heap dumps just to tell the user there are problems with their data model.

> Support streaming results
> -------------------------
>
>                 Key: CASSANDRA-8483
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-8483
>             Project: Cassandra
>          Issue Type: Sub-task
>          Components: Core
>            Reporter: Benedict
>             Fix For: 3.0
>
>
> Currently we stream the number of rows back to the client before serializing, which means we need to know how many there are before doing so, which means materializing the entire resultset. We currently get around this with paging which attempts to restrict the amount of materialization done in any step, but supporting streaming entire result sets in one native transport "action" without materializing them all upfront would remove the need for paging in many cases, and would permit resultsets to be streamed _with isolation_, which most users probably don't realise is broken by paging.
> We can't use this change yet, but the sooner support for this is introduced to the protocol, the more likely it is clients will be able to make use of streaming reads once we're actually able to deliver them.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)