[ 
https://issues.apache.org/jira/browse/IGNITE-6021?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vladimir Ozerov updated IGNITE-6021:
------------------------------------
    Description: 
This ticket should be done after IGNITE-6019. We should allow users to control 
how many pages to prefetch when executing queries. New API should be 
constructed carefully, taking in count the following considerations:
1) Sometimes user wants to get the first page ASAP, e.g. to display it on UI. 
In this case prefetch size should be 0. This is the best candidate for default 
value.
2) Sometimes user wants to get all results ASAP. E.g. for batch processing. In 
this case we should change our communication logic - instead of "request - 
response" model, we should employ "request - all responses" model, when we 
start query execution, and server pushes everything to the client without 
waiting for "next page request". This should be some special value, e.g. "-1".
3) And sometimes user want to have some real prefetch. E.g. because individual 
row processing on a client side is expensive, and user may benefit from 
concurrent fetching. In this case user should be able to set some positive 
integer defining how many pages to request in advance.

  was:
This ticket should be done after IGNITE-5019. We should allow users to control 
how many pages to prefetch when executing queries. New API should be 
constructed carefully, taking in count the following considerations:
1) Sometimes user wants to get the first page ASAP, e.g. to display it on UI. 
In this case prefetch size should be 0. This is the best candidate for default 
value.
2) Sometimes user wants to get all results ASAP. E.g. for batch processing. In 
this case we should change our communication logic - instead of "request - 
response" model, we should employ "request - all responses" model, when we 
start query execution, and server pushes everything to the client without 
waiting for "next page request". This should be some special value, e.g. "-1".
3) And sometimes user want to have some real prefetch. E.g. because individual 
row processing on a client side is expensive, and user may benefit from 
concurrent fetching. In this case user should be able to set some positive 
integer defining how many pages to request in advance.


> SQL: support asynchronous page prefetch on client side
> ------------------------------------------------------
>
>                 Key: IGNITE-6021
>                 URL: https://issues.apache.org/jira/browse/IGNITE-6021
>             Project: Ignite
>          Issue Type: Bug
>          Components: sql
>    Affects Versions: 2.1
>            Reporter: Vladimir Ozerov
>             Fix For: 2.2
>
>
> This ticket should be done after IGNITE-6019. We should allow users to 
> control how many pages to prefetch when executing queries. New API should be 
> constructed carefully, taking in count the following considerations:
> 1) Sometimes user wants to get the first page ASAP, e.g. to display it on UI. 
> In this case prefetch size should be 0. This is the best candidate for 
> default value.
> 2) Sometimes user wants to get all results ASAP. E.g. for batch processing. 
> In this case we should change our communication logic - instead of "request - 
> response" model, we should employ "request - all responses" model, when we 
> start query execution, and server pushes everything to the client without 
> waiting for "next page request". This should be some special value, e.g. "-1".
> 3) And sometimes user want to have some real prefetch. E.g. because 
> individual row processing on a client side is expensive, and user may benefit 
> from concurrent fetching. In this case user should be able to set some 
> positive integer defining how many pages to request in advance.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Reply via email to