[
https://issues.apache.org/jira/browse/CASSANDRA-8483?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14246733#comment-14246733
]
Sylvain Lebresne commented on CASSANDRA-8483:
---------------------------------------------
bq. but the goal here is only to introduce the capability to the clients so
they're ready well ahead of time
To clarify, I understood this was the intend. But I'm saying that there is
enough internal work to do imo that I don't think it's wise to introduce
complexity for drivers authors that might, perharps, never be actually used. Or
only in a long time. I'm fine brainstorming on how it could be done, but I'd
rather not include it in the v4 of the protocol.
> 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)
