ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Vladimir Ozerov (JIRA)" <j...@apache.org>
Subject [jira] [Created] (IGNITE-10985) SQL: create low-overhead implementation of Row for SELECTs
Date Fri, 18 Jan 2019 14:45:00 GMT
Vladimir Ozerov created IGNITE-10985:

             Summary: 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: Alexander Lapin
             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)

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

View raw message