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-10985) SQL: create low-overhead implementation of Row for SELECTs
Date Tue, 29 Jan 2019 15:27:00 GMT

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

Vladimir Ozerov updated IGNITE-10985:
-------------------------------------
    Labels: performance  (was: )

> SQL: create low-overhead implementation of Row for SELECTs
> ----------------------------------------------------------
>
>                 Key: IGNITE-10985
>                 URL: https://issues.apache.org/jira/browse/IGNITE-10985
>             Project: Ignite
>          Issue Type: Task
>          Components: sql
>            Reporter: Vladimir Ozerov
>            Assignee: Vladimir Ozerov
>            Priority: Major
>              Labels: performance
>             Fix For: 2.8
>
>
> Currently we use {{GridH2KeyValueRowOnheap}} for both update and search operations. This
leads to *huge* memory overhead during {{SELECT}} execution. If you take a closer look on
what is inside the row, you will note the following:
> # It has both serialized and deserialized {{GridCacheVersion}} which is never needed
> # It has wrapped key and value object
> # It has reference to {{CacheDataRow}} which is not needed either
> # It has {{valCache}} field which is never used in SELECT
> The goal of this ticket is to created optimized version of row which will be created
during {{SELECT}} operations only. It should contain only minimally necessary information:
> # Key (unwrapped!)
> # Value (unwrapped!)
> # Version (unwrapped, we will remove it completely in separate ticket IGNITE-10986)
> It should not contain reference to {{CacheDataRow}}. There is a chance that we will need
some pieces from it (e.g. cache ID and link for caching purposes), but it definitely will
be only small subset of the whole {{CacheDataRowAdapter}} (or even worse - {{MvccDataRow}}).
> Entry point: {{H2Tree.createRowFromLink}} methods. Note that they return {{GridH2Row}},
while in their usages only very relaxed version of {{GridH2SearchRow}} is needed. So let's
start with new implementation of row for these methods and then gradually remove all unnecessary
stuff from there.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Mime
View raw message