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.
Example:
Logical plan with a leaf nodes in a custom convention:
LogicalSort[NONE] LogicalProject[NONE] CustomScan[CUSTOM_CONVENTION]
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.
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.
Attachments
Issue Links
- is caused by
-
CALCITE-3939 Change UnionEliminatorRule and ProjectRemoveRule to auto pruning SubstitutionRule
- Closed