[jira] [Comment Edited] (CALCITE-4029) ProjectRemoveRule auto pruning may prevent rules from running if mixed conventions are used in a logical plan

["Anton Haidai (Jira)" <ji...@apache.org>]

    [ 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)