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] [Commented] (IGNITE-6945) SQL: optionally do not copy offheap rows for local SqlQuery
Date Tue, 28 Nov 2017 14:32:00 GMT

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

Vladimir Ozerov commented on IGNITE-6945:

[~tledkov-gridgain], my comments:
1) BinaryObjectOffheapImpl: I think it is illegal to "copy" object this way. We should copy
data from offheap to heap and return BinaryObjectImpl.
2) Usage of GridCloseableCursor and/or Closeable is bad idea, because this may lead to unexpected
calls to "close" in future. Let's define separate interface for this.
3) Why do we push flag to CacheOperationContext? Looks wrong to me, as it doesn't relate to
cache. This is indexing stuff, GridH2QueryContext should be enough.
4) H2Tree.compare - why do we cleanup temp row in one place, but do not do this after another
getRow() call below?
5) Is it possible to remove all current changes from BPlusTree and perform close in H2 classes?
It looks strange that we call unrelated unlocks in all tree types just to support local SQL
queries. You can do that as follows: define a kind of registry of binary objects to be closed;
pass it to BPlusTree when cursor is created; use it inside H2LeafIO and H2ExtrasLeadIO classes
to track pages to be unlocked. Will that work? Ideally, there should be no changes to BPlusTree
and CacheDataRow.

> SQL: optionally do not copy offheap rows for local SqlQuery
> -----------------------------------------------------------
>                 Key: IGNITE-6945
>                 URL: https://issues.apache.org/jira/browse/IGNITE-6945
>             Project: Ignite
>          Issue Type: Task
>          Components: sql
>            Reporter: Vladimir Ozerov
>            Assignee: Taras Ledkov
>             Fix For: 2.4
> Currently when iterating over rows we eagerly materialize them [1]. If key or value are
large enough, we could loose a lot of time on offheap-heap copying. To partially mitigate
this, we can do the following:
> 1) Add new flag {{SqlQuery.localNoCopy}} which is applicable only for local queries.
> 2) When enabled we will not copy final {{_KEY}} and {{_VAL}} columns to heap. but rather
wrap them into {{BinaryOffheapObjectImpl}}
> 3) These rows must be released when query iterator switches to the next row.
> [1] {{H2RowFactory.getRow}}

This message was sent by Atlassian JIRA

View raw message