[ 
https://issues.apache.org/jira/browse/CALCITE-4029?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17120768#comment-17120768
 ] 

Botong Huang commented on CALCITE-4029:
---------------------------------------

This hack I proposed indeed won't work. 
{quote}
If you really want it to fire, consider changing the child operand in RuleX to 
match any convention. (btw, when you write operand(LogicalSort.class, 
operand(RelNode.class, any())) earlier, this should already match the 
customScan with a custom convention right?
{quote}

But again, I insist on this: logical project/sort having a non logical 
CustomScan as input is a weird design. This is the fundamental reason you are 
seeing this issue. 

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

Reply via email to