[ 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)