[
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
(v6.4.14#64029)
