You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@ignite.apache.org by "Vladimir Ozerov (JIRA)" <ji...@apache.org> on 2018/03/19 08:45:00 UTC

[jira] [Updated] (IGNITE-6021) SQL: support asynchronous page prefetch on client side

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

Vladimir Ozerov updated IGNITE-6021:
------------------------------------
    Labels: performance sql-performance  (was: performance)

> SQL: support asynchronous page prefetch on client side
> ------------------------------------------------------
>
>                 Key: IGNITE-6021
>                 URL: https://issues.apache.org/jira/browse/IGNITE-6021
>             Project: Ignite
>          Issue Type: Task
>          Components: sql
>    Affects Versions: 2.1
>            Reporter: Vladimir Ozerov
>            Priority: Major
>              Labels: performance, sql-performance
>
> 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
(v7.6.3#76005)