suibianwanwank commented on PR #4614:
URL: https://github.com/apache/calcite/pull/4614#issuecomment-3486907018
I believe there's way for optimization here, but merely considering LEFT and
COUNT doesn't seem sufficient in my view.
Test in sub-query.iq:
```
SELECT deptno, (SELECT CASE WHEN SUM(sal) > 10 then 'VIP' else 'Regular' END
expr
FROM emp e
WHERE d.deptno = e.deptno) a
FROM dept d;
!ok
```
Currently, this query will be decorrelated by hepPlanner. Suppose we remove
HepPlanner.
```
--- a/core/src/main/java/org/apache/calcite/sql2rel/RelDecorrelator.java
+++ b/core/src/main/java/org/apache/calcite/sql2rel/RelDecorrelator.java
@@ -247,9 +247,7 @@ public static RelNode decorrelateQuery(RelNode rootRel,
new RelDecorrelator(corelMap,
cluster.getPlanner().getContext(), relBuilder);
- RelNode newRootRel = decorrelationRules == null
- ? decorrelator.removeCorrelationViaRule(rootRel)
- : decorrelator.removeCorrelationViaRule(rootRel,
decorrelationRules);
+ RelNode newRootRel = rootRel;
if (SQL2REL_LOGGER.isDebugEnabled()) {
SQL2REL_LOGGER.debug(
@@ -324,7 +322,7 @@ protected RelNode decorrelate(RelNode root) {
HepPlanner planner = createPlanner(program);
planner.setRoot(root);
- root = planner.findBestExp();
+// root = planner.findBestExp();
if (SQL2REL_LOGGER.isDebugEnabled()) {
SQL2REL_LOGGER.debug("Plan before extracting correlated
computations:\n"
+ RelOptUtil.toString(root));
```
After this PR, the decorrelator will return incorrect results.
```
DEPTNO | A
--------+---------
10 | VIP
20 | VIP
30 | VIP
40 | NULL
```
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
