You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@calcite.apache.org by "Botong Huang (Jira)" <ji...@apache.org> on 2020/06/01 06:10:00 UTC

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

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