[mihaibudiu]

Jira Link

CALCITE-7930

I am not thrilled by this solution, because it uses a switch statement over the aggregates to decide their behavior. So it's not extensible to adding new aggregate functions without changing the decorrelator. A solution that does not look at the aggregate can be implemented, but generates an extra join in some plans.

The same bug exists in both decorrelators.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
82.4% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[silundong]

When I first looked at these test cases, I thought TopDownGeneralDecorrelator should theoretically handle them correctly. Given an execution plan like this:

LogicalAggregate(group=[{}], EXPR$0=[COUNT()])
  LogicalAggregate(group=[{0}], groups=[[{0}, {}]], EXPR$0=[COUNT()])

it would introduce a left join for the second Aggregate, as ensured by the following condition in unnestInternal:

if (aggregate.hasEmptyGroup()
    && (!allowEmptyOutputFromRewrite || hasCountFunction)) {
  ...
}

However, after printing the execution plan, I found that TopDownGeneralDecorrelator actually receives the following:

LogicalAggregate(group=[{}], EXPR$0=[COUNT()])
    LogicalAggregate(group=[{0}], groups=[[{0}, {}]])

The second Aggregate does not contain a COUNT function, so the condition above was not satisfied.

[mihaibudiu]

I read your comment as an explanation of the previous implementation, and not as something that needs to be addressed. I plan to merge this.