[
https://issues.apache.org/jira/browse/KUDU-1695?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15569332#comment-15569332
]
Todd Lipcon commented on KUDU-1695:
-----------------------------------
The memory for a scan is split into two buffers: one is the 'direct data' which
is the row tuples themselves. The second is the 'indirect data' which is stuff
like binary columns pointed to by the row tuple data.
The ability to "release" the indirect data makes a lot of sense and seems like
the kind of API we can maintain long term, since the buffer isn't being
"interpreted" in any way. For the direct tuple data, I think it would make
sense to do an API something like:
{code}
enum RowLayout {
KUDU_LAYOUT_1
};
// Release the row data from the scanner result batch.
// If the specified layout isn't supported for this scan, this may return NULL.
void* ReleaseRowData(RowLayout layout);
{code}
The idea here is that, if we were to switch to a different row layout
internally in a future version, the API wouldn't break - it would just return
NULL and force users of it to either fallback or report a nice error rather
than crashing.
Does something like that sound reasonable?
> C++ client support for zero copy scans
> --------------------------------------
>
> Key: KUDU-1695
> URL: https://issues.apache.org/jira/browse/KUDU-1695
> Project: Kudu
> Issue Type: New Feature
> Components: client
> Affects Versions: 1.0.0
> Reporter: Matthew Jacobs
> Labels: impala
>
> Copying tuples from the Kudu client is expensive. Impala would like to be
> able avoid this copy if the Kudu client can provide a mechanism to transfer
> the memory ownership.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
