[
https://issues.apache.org/jira/browse/CALCITE-2997?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17111699#comment-17111699
]
Jin Xing edited comment on CALCITE-2997 at 5/20/20, 2:36 AM:
-
Thanks [~swtalbot] and [~julianhyde] to bring this up ~
Yes, In some scenarios we need SqlToRelConverter to return a logical plan which
corresponds to original SQL String exactly.
Mixing optimizations into the process of building logical plan sometimes make
the user confused.
I would +1 on Julian's idea – – move the rewrite/optimize code into RelBuilder
and add a config to enable/disable, but several concerns as below:
# Should we disable the rewrite/optimize in SqlToRelConverter by default ?
Calcite have clear phases for the lifecycle of a SQL. SqlToRelConverter can
return a purely reflection of the original SQL string, and let the
optimization/rewrite done in the following optimizing phase;
# In addition to pushDownJoinConditions, there are other rewrites like
pushDownNotForIn, shall we disable these optimizing work by default or even
move out of SqlToRelConverter to the optimizaing phase ?
was (Author: jinxing6...@126.com):
Thanks [~swtalbot] and [~julianhyde] to bring this up ~
Yes, In some scenarios we need SqlToRelConverter to return a logical plan which
corresponds to original SQL String exactly.
Mixing optimizations into the process of building logical plan sometimes make
the user confused.
I would +1 on Julian's idea – – move the rewrite/optimize code into RelBuilder
and add a config to enable/disable, but several concerns as below:
# Should we disable the rewrite/optimize in SqlToRelConverter by default ?
Calcite have clear phases for the lifecycle of a SQL. SqlToRelConverter can
return a purely reflection of the original SQL string, and let the
optimization/rewrite done in the following optimizing phase;
# In addition to pushDownJoinConditions, there are other rewrites like
pushDownNotForIn, shall we disable these optimizing work or even move out of
SqlToRelConverter to the optimizaing phase ?
> Avoid pushing down join condition in SqlToRelConverter
> --
>
> Key: CALCITE-2997
> URL: https://issues.apache.org/jira/browse/CALCITE-2997
> Project: Calcite
> Issue Type: Bug
>Reporter: Jin Xing
>Assignee: Julian Hyde
>Priority: Major
>
> In current code, *SqlToRelConverter:createJoin* is calling
> *RelOptUtil.pushDownJoinConditions* for optimization. And we can find below
> conversion from *SqlNode* to *RelNode*:
> {code:java}
> SqlNode:
> select * from A join B on A.x = B.x * 2
> RelNode (Logical-Plan):
> Join (condition:col0=col1)
> |-Project(x as col0)
> | |-Scan(A)
> |-Project(x * 2 as col1)
> |-Scan(B){code}
> As we can see the logical plan(*RelNode*) posted above is not the pure
> reflection of the original SQL String(*SqlNode*). The optimization is mixed
> into the phase on which AST is converted to Logical-Plan. Actually optimizing
> rule of JoinPushExpressionsRule is doing exactly the same kind of thing.
> Shall we just keep the optimization inside Optimized-Logical-Plan ? I mean
> shall we avoid calling *RelOptUtil.pushDownJoinConditions* in
> *SqlToRelConverter:createJoin*
> I raised this issue because that we are doing something based on the
> Logical-Plan. And it makes us really confused that the Logical-Plan doesn't
> corresponds to SqlNode.
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
