ignite-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ignite TC Bot (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (IGNITE-7948) SQL: read only necessary fields into the row when possible
Date Tue, 19 Feb 2019 13:30:00 GMT

    [ https://issues.apache.org/jira/browse/IGNITE-7948?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16771924#comment-16771924

Ignite TC Bot commented on IGNITE-7948:

{panel:title=--&gt; Run :: All: No blockers found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity *--&gt; Run :: All* Results|https://ci.ignite.apache.org/viewLog.html?buildId=3113559&amp;buildTypeId=IgniteTests24Java8_RunAll]

> SQL: read only necessary fields into the row when possible
> ----------------------------------------------------------
>                 Key: IGNITE-7948
>                 URL: https://issues.apache.org/jira/browse/IGNITE-7948
>             Project: Ignite
>          Issue Type: Task
>          Components: sql
>            Reporter: Vladimir Ozerov
>            Assignee: Taras Ledkov
>            Priority: Major
>             Fix For: 2.8
> When H2 row is read, we always fill it with data eagerly through link materialization.
Materialization is performed under page "read lock" what guarantees row-level consistency.
This may lead to excessive memory pressure due to memory copying. For example, consider a
class with 50 fields and a query which reads only 2 of them. 48 other fields will be copied
without a reason. Lazy initialization is not an option because it will only defer memcpy,
but not eliminate it. 
> Instead we can try using H2. It passes {{TableFilter}} class to some of index access
methods*. We can analyze this class and create the list of required fields. Then we can read
these fields under read lock from offheap and put them to the row.
> In addition to saved memcpy this could give us more benefits:
> 1) No more need for field cache ({{GridH2KeyValueRowOnheap#valCache}})
> 2) No more need to read {{_VER}} column and possibly {{_KEY}} or {{_VAL}}
> But there are a number of drawbacks as well. E.g. it is impossible to read strings from
offheap efficiently, so queries with VARCHAR will definitely suffer from this change.
> \* {{org.h2.index.Index#find(org.h2.table.TableFilter, org.h2.result.SearchRow, org.h2.result.SearchRow)}}

This message was sent by Atlassian JIRA

View raw message