[
https://issues.apache.org/jira/browse/CALCITE-3939?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17118720#comment-17118720
]
Anton Haidai commented on CALCITE-3939:
---------------------------------------
FYI:
This change caused a regression on our side (with a trivial fix available).
I can't provide the test reproducing it as far as a custom rule (RuleX in a
description next) is involved, but I can describe the flow.
Preconditions:
RuleX is configured to match operand(LogicalSort.class, operand(RelNode.class,
any())).
Logical plan is:
{code:java}
LogicalSort(fetch=[5])
LogicalProject(id=[$0], name=[$1], customer_type=[$2], address_state=[$3],
address_city=[$4], zip_code=[$5], birth_date=[$6], registration_date=[$7],
registration_date_year=[$8], last_purchase_date=[$9])
CustomScan(){code}
This LogicalProject is trivial.
Flow:
# RuleX.matches() returns true, call nodes are LogicalSort, LogicalProject
# ProjectRemoveRule.onMatch() is called on LogicalProject and removes the
trivial project.
# RuleX.onMatch() is never called while it can produce a desirable
transformation: there are other nodes in the same RelSet with the removed
LogicalProject.
The trivial fix we used is just to make ProjectRemoveRule.autoPruneOld() to
return false reverting this fix.
I'm not sure if this is a bug and we have a workaround so this is just FYI.
> Change UnionEliminatorRule and ProjectRemoveRule to auto pruning
> SubstitutionRule
> ---------------------------------------------------------------------------------
>
> Key: CALCITE-3939
> URL: https://issues.apache.org/jira/browse/CALCITE-3939
> Project: Calcite
> Issue Type: Improvement
> Reporter: Botong Huang
> Priority: Major
> Fix For: 1.23.0
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> UnionEliminatorRule and ProjectRemoveRule are both pruning rules for a
> RelNode. They can also become SubstitutionRule with autoprune enabled
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
