[CALCITE-3495] RelDecorrelator generate plan with different semantics when handle Aggregate#1670
[CALCITE-3495] RelDecorrelator generate plan with different semantics when handle Aggregate#1670yanlin-Lynn wants to merge 1 commit intoapache:masterfrom
Conversation
yanlin-Lynn
force-pushed
the
decorrelate-count
branch
from
30423e1 to
328edd2
Compare
| if (aggFunctionNotFitToDecorrelate(call.getAggregation())) { | ||
| return null; | ||
| } | ||
| } |
There was a problem hiding this comment.
Should we allow count agg for subquery where the group key is not empty? e.g.
select * from foo where (a, b) in (select c, count(*) from bar where bar.d=foo.d group by c)
There was a problem hiding this comment.
But I am not sure Calcite can decorrelate it or not.
There was a problem hiding this comment.
Rather than failing the decorrelation when COUNT, do we consider just disable decorrelation when subquery is an Aggregate?
Because user have the flexibility to define UDAF, it's hard to predicate the Agg behavior or enumerate all types of Agg functions.
There was a problem hiding this comment.
@yanlin-Lynn
If the PR is already for review, could you please remove [WIP] from PR title ?
There was a problem hiding this comment.
@hsyuan , yes, we can allow that when group key is not empty. I add a test case for that.
@jinxing64 RelDecorrelator.decorrelateQuery is a public method, user may call it directly. So, I would perfer to fail the decorrelation. But, your concern is valid, so I add the check for UDAF. How about that.
There was a problem hiding this comment.
Thanks @yanlin-Lynn
I would hear committers' advice.
yanlin-Lynn
changed the title
… when handle Aggregate (Wang Yanlin)
yanlin-Lynn
force-pushed
the
decorrelate-count
branch
from
328edd2 to
006bd94
Compare
vlsi
force-pushed
the
master
branch
2 times, most recently
from
49cb002 to
8768a23
Compare
3 participants
In some case, the semantics of sql is changed after decorrelated, see CALCIT-3495 for detail.
This PR tries to fail the decorrelation for this kind of sql.