ignite-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Vladimir Ozerov (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (IGNITE-6021) SQL: support asynchronous page prefetch on client side
Date Thu, 10 Aug 2017 08:24:00 GMT

     [ 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)

Mime
View raw message