[ https://issues.apache.org/jira/browse/IMPALA-12183?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17731703#comment-17731703 ]
ASF subversion and git services commented on IMPALA-12183: ---------------------------------------------------------- Commit 81a41fca6dee014f11695f553ecdb6c82a172d0a in impala's branch refs/heads/master from Riza Suminto [ https://gitbox.apache.org/repos/asf?p=impala.git;h=81a41fca6 ] IMPALA-12183: Fix cardinality clamping across aggregation phases In the Impala planner, an aggregation node's cardinality is a sum of all its aggregation class cardinality. An aggregation class cardinality is a simple multiplication of NDVs of contributing grouping columns. Since this simple multiplication of NDVs can be greater than the aggregation node's input cardinality, each aggregation class cardinality is further clamped at the aggregation node's input cardinality. An aggregation operator can translate into a chain of multi-phase aggregation plan nodes. The longest possible aggregation phase is as follows, from the bottom to the top: 1. FIRST 2. FIRST_MERGE 3. SECOND 4. SECOND_MERGE 5. TRANSPOSE FIRST_MERGE aggregation maintains its aggregation class cardinality clamping at its corresponding FIRST aggregation's input cardinality (similar relationship between SECOND_MERGE and SECOND). However, the SECOND aggregation was clamped at the FIRST_MERGE output cardinality instead of the FIRST input cardinality. This cardinality mispropagation can causes cardinality explosion in the later aggregation phase and node operator above them. This patch fix the clamping of multi-phase aggregation to always look at input cardinality of FIRST aggregation node. An exception is made for TRANSPOSE phase of grouping set aggregation (such as ROLLUP). In that case, cardinality clamping will use output cardinality of child node right below it (either FIRST_MERGE or SECOND_MERGE) because the output cardinality of the whole aggregation chain can be higher than input cardinality of the FIRST phase. Testing: - Add test in card-agg.test - Pass core tests. Change-Id: I1d414fe56b027f887c7f901d8a6799a388b16b95 Reviewed-on: http://gerrit.cloudera.org:8080/20009 Reviewed-by: Aman Sinha <amsi...@cloudera.com> Tested-by: Impala Public Jenkins <impala-public-jenk...@cloudera.com> > Maintain cardinality clamping across multi-phase aggregation > ------------------------------------------------------------ > > Key: IMPALA-12183 > URL: https://issues.apache.org/jira/browse/IMPALA-12183 > Project: IMPALA > Issue Type: Bug > Components: Frontend > Affects Versions: Impala 4.2.0 > Reporter: Riza Suminto > Assignee: Riza Suminto > Priority: Major > Fix For: Impala 4.3.0 > > > In the Impala planner, an aggregation node's cardinality is a sum of all its > aggregation class cardinality. An aggregation class cardinality is a simple > multiplication of NDVs of contributing grouping columns. Since this simple > multiplication of NDVs can be greater than the aggregation node's input > cardinality, each aggregation class cardinality is further clamped at the > aggregation node's input cardinality. > An aggregation operator can translate into a chain of multi-phase aggregation > plan nodes. The longest possible aggregation phase is as follows, from the > bottom to the top: > # FIRST > # FIRST_MERGE > # SECOND > # SECOND_MERGE > # TRANSPOSE > FIRST_MERGE aggregation maintains its aggregation class cardinality clamping > at its corresponding FIRST aggregation's input cardinality (similar > relationship between SECOND_MERGE and SECOND). However, the SECOND > aggregation was clamped at the FIRST_MERGE output cardinality instead of the > FIRST input cardinality. This cardinality mispropagation can causes > cardinality explosion in the later aggregation phase and node operator above > them. -- This message was sent by Atlassian Jira (v8.20.10#820010) --------------------------------------------------------------------- To unsubscribe, e-mail: issues-all-unsubscr...@impala.apache.org For additional commands, e-mail: issues-all-h...@impala.apache.org