[
https://issues.apache.org/jira/browse/DRILL-6126?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16385717#comment-16385717
]
ASF GitHub Bot commented on DRILL-6126:
---------------------------------------
Github user paul-rogers commented on a diff in the pull request:
https://github.com/apache/drill/pull/1125#discussion_r172103839
--- Diff:
exec/java-exec/src/main/java/org/apache/drill/exec/physical/impl/join/MergeJoinBatch.java
---
@@ -492,8 +504,12 @@ private void allocateBatch(boolean newSchema) {
} else {
container.zeroVectors();
}
+
+ // Allocate memory for the vectors.
+ // This will iteratively allocate memory for all nested columns
underneath.
for (VectorWrapper w : container) {
- AllocationHelper.allocateNew(w.getValueVector(),
Character.MAX_VALUE);
+ RecordBatchSizer.ColumnSize colSize =
mergeJoinMemoryManager.getColumnSize(w.getField().getName());
+ colSize.allocateVector(w.getValueVector(),
mergeJoinMemoryManager.getOutputRowCount());
--- End diff --
Nice! Much simpler. Just one nit: might as well get the row count once and
store it in a local variable to avoid getting the same number repeatedly.
> Allocate memory for value vectors upfront in flatten operator
> -------------------------------------------------------------
>
> Key: DRILL-6126
> URL: https://issues.apache.org/jira/browse/DRILL-6126
> Project: Apache Drill
> Issue Type: Improvement
> Reporter: Padma Penumarthy
> Assignee: Padma Penumarthy
> Priority: Critical
> Fix For: 1.12.0
>
>
> With recent changes to control batch size for flatten operator, we figure out
> row count in the output batch based on memory. Since we know how many rows we
> are going to include in the batch, we can also allocate the memory needed
> upfront instead of starting with initial value (4096) and doubling, copying
> every time we need more.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
