[
https://issues.apache.org/jira/browse/CALCITE-5448?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17650000#comment-17650000
]
Mihai Budiu commented on CALCITE-5448:
--------------------------------------
I have traced the flow of execution in my project.
I am using a SqlToRelConverter whose planner (in my case an instance of
HepPlanner) does not have an executor.
The RelNode rel that is produced from this converter has
rel.getCluster().getPlanner().getExecutor() == null.
For such RelNodes the CoreRules.PROJECT_REDUCE_EXPRESSIONS rule does nothing.
If I do set an executor in the planner of the converter the optimizations work
correctly.
I was trying to create a reproduction in Calcite, but the TestFixture always
makes sure the SqlToRelConverter's planner has an executor, so this does not
arise. Is there a set of tests in Calcite to test such hand-crafted compilation
flows where I could insert my test case?
Nevertheless, I think there is at least some code usability bug here:
{{reduceExpressionsInternal }}has access to multiple executors (one through the
RelNode, the other through the RexSimplify object), and to the function caller
it's not clear which one will be used. The intent in reduceExpressionsInternal
seems to be that the one in RexSimplify will be used, but that's not what
happens.
Can the two executors be different? If not, perhaps an assertion should check
that they aren't. Alternatively, perhaps reduceExpressionsInternal could give a
warning if the executor used is null.
I am a relatively new user of Calcite, so I haven't yet fully internalized the
structure of the rich object hierarchy and the role of each of the pieces in
the compilation flow.
> ReduceExpressionsRule does not always constant fold expressions
> ----------------------------------------------------------------
>
> Key: CALCITE-5448
> URL: https://issues.apache.org/jira/browse/CALCITE-5448
> Project: Calcite
> Issue Type: Bug
> Components: core
> Affects Versions: 1.32.0
> Reporter: Mihai Budiu
> Priority: Minor
>
> I have manually built a HepPlanner to optimize the SQL queries, and I
> discovered that the rule ReduceExpressionsRule does not really do anything in
> my setup.
> I am looking at method ReduceExpressionsRule.reduceExpressionsInternal.
> There is this piece of code:
> {code}
> RexExecutor executor = rel.getCluster().getPlanner().getExecutor();
> if (executor == null) {
> // Cannot reduce expressions: caller has not set an executor in their
> // environment. Caller should execute something like the following
> before
> // invoking the planner:
> //
> // final RexExecutorImpl executor =
> // new RexExecutorImpl(Schemas.createDataContext(null));
> // rootRel.getCluster().getPlanner().setExecutor(executor);
> return changed;
> }
> {code}
>
> However, the caller of this function, the method reduceExpressions, has
> carefully inserted an executor in the RexSimplify class in case the cluster
> has no executor. Shouldn't that executor be used instead of trying the
> missing one? (It is currently private in the RexSimplify class.)
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
