HanumathRao commented on code in PR #3193:
URL: https://github.com/apache/calcite/pull/3193#discussion_r1205054838
##########
core/src/main/java/org/apache/calcite/rel/rules/SubQueryRemoveRule.java:
##########
@@ -866,6 +866,8 @@ private static void matchFilter(SubQueryRemoveRule rule,
LogicVisitor.find(RelOptUtil.Logic.TRUE, ImmutableList.of(c), e);
final Set<CorrelationId> variablesSet =
RelOptUtil.getVariablesUsed(e.rel);
+ /* Only consider the correlated variables which originated from this
sub-query level*/
+ variablesSet.retainAll(filter.getVariablesSet());
Review Comment:
Agree that this fix is using the existing mechanism to set the variable in
Filter operator, I did have questions like what happens when there other
operator nodes etc. I want to handle the specific case for this PR(as you
mentioned going in the right direction) and handle as we have more use cases
(please let me know if it makes sense).
Agree with you that this code might result in a throwing an exception in
cases where previous code was generating a plan. However, I encountered a
scenario while debugging the
JIRA([CALCITE-5716](https://issues.apache.org/jira/browse/CALCITE-5716))
wherein it was not reporting an error but generating a wrong plan. With the fix
provided in this PR it is generating a right result (when running a generated
plan). Updated the JIRA with the analysis
--
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]
