You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues-all@impala.apache.org by "ASF subversion and git services (Jira)" <ji...@apache.org> on 2023/06/12 17:04:00 UTC
[jira] [Commented] (IMPALA-12183) Maintain cardinality clamping across multi-phase aggregation
[ 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 <am...@cloudera.com>
Tested-by: Impala Public Jenkins <im...@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-unsubscribe@impala.apache.org
For additional commands, e-mail: issues-all-help@impala.apache.org