[
https://issues.apache.org/jira/browse/CALCITE-4029?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17120999#comment-17120999
]
Anton Haidai edited comment on CALCITE-4029 at 6/1/20, 1:06 PM:
----------------------------------------------------------------
[~botong],
I agree, for example, even after a hypothetical CALCITE-3939 revert (so the
Project over the CustomScan will be preserved), exactly the same issue will be
faced if some RuleY matches "operand(LogicalProject.class,
operand(RelNode.class, any()))": it could be expected that it will fire, but it
won't.
So I'm ok with a rejection of this ticket. Reporting this issue faced in our
system was FYI from the beginning :).
was (Author: anha):
[~botong]
I agree, for example, even after a hypothetical CALCITE-3939 revert (so the
Project over the CustomScan will be preserved), exactly the same issue will be
faced if some RuleY matches "operand(LogicalProject.class,
operand(RelNode.class, any()))": it could be expected that it will fire, but it
won't.
So I'm ok with a rejection of this ticket. Reporting this issue in our system
was FYI from the beginning :).
> ProjectRemoveRule auto pruning may prevent rules from running if mixed
> conventions are used in a logical plan
> --------------------------------------------------------------------------------------------------------------
>
> Key: CALCITE-4029
> URL: https://issues.apache.org/jira/browse/CALCITE-4029
> Project: Calcite
> Issue Type: Bug
> Components: core
> Affects Versions: 1.23.0
> Reporter: Anton Haidai
> Priority: Minor
>
> Preconditions to reproduce the issue:
> # Logical plan has mixed conventions (for example, a bottom node is a
> TableScan in a final convention while other nodes are regular logical nodes
> with NONE convention).
> # There is a rule that expects a logical node with an input (like a rule
> matching "operand(LogicalSort.class, operand(RelNode.class, any()))")
> # A project over the scan is trivial (like SELECT * FROM ...)
> The issue is related to https://issues.apache.org/jira/browse/CALCITE-3939,
> please see comments for a detailed debugging of a real-life reproducing case.
> h4. Example:
> Logical plan with a leaf nodes in a custom convention:
> {code:java}
> LogicalSort[NONE]
> LogicalProject[NONE]
> CustomScan[CUSTOM_CONVENTION]{code}
> A rule configured (RuleX) matches "operand(LogicalSort.class,
> operand(RelNode.class, any()))".
> *Without ProjectRemoveRule auto pruning*
> ProjectRemoveRule recognizes LogicalProject as trivial an merges it into a
> single RelSet with CustomScan.
> RuleX can run on top of this change as far as LogicalProject has a logical
> node (LogicalProject in RelSubset[NONE]) as an input.
>
> *With ProjectRemoveRule auto pruning*
> ProjectRemoveRule recognizes LogicalProject as trivial but removes it with
> it's RelSet so the CustomScan is the only node in it's RelSet,
> RelSubset[CUSTOM_CONVENTION].
> RuleX can't run on top of this change as far as LogicalProject has an empty
> input RelSubset[NONE] of the RelSet with the CustomScan.
> h2. Possible workarounds
> # Disable ProjectRemoveRule auto pruning.
> # Use only logical nodes in a logical plan, for the example above: use
> LogicalScan - > CustomScanRule - > CustomScan instead of direct use of
> CustomScan.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
