[ https://issues.apache.org/jira/browse/PHOENIX-2606?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15106891#comment-15106891 ]
Sudarshan Kadambi commented on PHOENIX-2606: -------------------------------------------- I reviewed how RVCs could be used to implement paging. Cursors over RVCs appear to be the right way to get this started. Such an implementation would primarily be a convenience aid in terms of not requiring the client to capture the last value(s) and rebind them as the RVC parameters in the query. > Cursor support in Phoenix > ------------------------- > > Key: PHOENIX-2606 > URL: https://issues.apache.org/jira/browse/PHOENIX-2606 > Project: Phoenix > Issue Type: New Feature > Reporter: Sudarshan Kadambi > > Phoenix should look to support a cursor model where the user could set the > fetch size to limit the number of rows that are fetched in each batch. Each > batch of result rows would be accompanied by a flag indicating if there are > more rows to be fetched for a given query or not. > The state management for the cursor could be done in the client side or > server side (i.e. HBase, not the Query Server). The client side state > management could involve capturing the last key in the batch and using that > as the start key for the subsequent scan operation. The downside of this > model is that if there were any intervening inserts or deletes in the result > set of the query, backtracking on the cursor would reflect these additional > rows (consider a page down, followed by a page up showing a different set of > result rows). Similarly, if the cursor is defined over the results of a join > or an aggregation, these operations would need to be performed again when the > next batch of result rows are to be fetched. > So an alternate approach could be to manage the state server side, wherein > there is a query context area in the Regionservers (or, maybe just a > temporary table) and the cursor results are fetched from there. This ensures > that the cursor has snapshot isolation semantics. I think both models make > sense but it might make sense to start with the state management completely > on the client side. -- This message was sent by Atlassian JIRA (v6.3.4#6332)