[ 
https://issues.apache.org/jira/browse/DRILL-6310?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16516692#comment-16516692
 ] 

ASF GitHub Bot commented on DRILL-6310:
---------------------------------------

ilooner commented on a change in pull request #1324: DRILL-6310: limit batch 
size for hash aggregate
URL: https://github.com/apache/drill/pull/1324#discussion_r196300145
 
 

 ##########
 File path: 
exec/java-exec/src/main/java/org/apache/drill/exec/physical/impl/common/HashTableTemplate.java
 ##########
 @@ -111,6 +111,31 @@
 
   private int resizingTime = 0;
 
+
+  // Given hashtable index, figure out the corresponding index in the batch.
+  public int idxInBatch(int idx) {
 
 Review comment:
   This complexity comes from the heterogenous BatchHolder sizes. Additionally 
there is a performance penalty for calculating indexes as the HashTable gets 
larger. As my comment above mentions, I don't think there is any benefit to 
having different sizes for batch holders. We should compute a reasonable size 
based on the first set of input data, and then use the same BatchHolder size 
everywhere.

----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> limit batch size for hash aggregate
> -----------------------------------
>
>                 Key: DRILL-6310
>                 URL: https://issues.apache.org/jira/browse/DRILL-6310
>             Project: Apache Drill
>          Issue Type: Improvement
>          Components: Execution - Flow
>    Affects Versions: 1.13.0
>            Reporter: Padma Penumarthy
>            Assignee: Padma Penumarthy
>            Priority: Major
>             Fix For: 1.14.0
>
>
> limit batch size for hash aggregate based on memory.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Reply via email to