[
https://issues.apache.org/jira/browse/CALCITE-4029?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anton Haidai updated CALCITE-4029:
----------------------------------
Description:
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 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.
was:
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 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.
> 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 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)
