[
https://issues.apache.org/jira/browse/DRILL-3993?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16326560#comment-16326560
]
ASF GitHub Bot commented on DRILL-3993:
---------------------------------------
Github user chunhui-shi commented on a diff in the pull request:
https://github.com/apache/drill/pull/1066#discussion_r161607926
--- Diff:
exec/java-exec/src/main/java/org/apache/drill/exec/physical/impl/aggregate/HashAggTemplate.java
---
@@ -1303,6 +1305,8 @@ private void checkGroupAndAggrValues(int
incomingRowIdx) {
long memDiff = allocator.getAllocatedMemory() - allocatedBeforeHTput;
if ( memDiff > 0 ) { logger.warn("Leak: HashTable put() OOM left
behind {} bytes allocated",memDiff); }
+ checkForSpillPossibility(currentPartition);
--- End diff --
Not sure this check 'chooseAPartitionToFlush' is needed. If an exception
is desired, I would think modifying doSpill() is better way e.g. modifying this
line: " if ( victimPartition < 0 ) { return; } " Otherwise in this process
chooseAPartitionToFlush will be called twice.
int victimPartition = chooseAPartitionToFlush(currentPartition,
forceSpill);
// In case no partition has more than one batch -- try and "push the
limits"; maybe next
// time the spill could work.
if ( victimPartition < 0 ) { return; }
> Rebase Drill on Calcite master branch
> -------------------------------------
>
> Key: DRILL-3993
> URL: https://issues.apache.org/jira/browse/DRILL-3993
> Project: Apache Drill
> Issue Type: Bug
> Components: Query Planning & Optimization
> Affects Versions: 1.2.0
> Reporter: Sudheesh Katkam
> Assignee: Roman Kulyk
> Priority: Major
>
> Calcite keeps moving, and now we need to catch up to Calcite 1.5, and ensure
> there are no regressions.
> Also, how do we resolve this 'catching up' issue in the long term?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
