[
https://issues.apache.org/jira/browse/CALCITE-4936?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maksim Gramin updated CALCITE-4936:
-----------------------------------
Description:
I noticed that rules ProjectCalcMergeRule and FilterCalcMergeRule strictly
dependent on LogicalCalc class (e.g. casting call.rel to LogicalCalc, using
LogicalCalc.create method and etc). I suggest making them more generalized
(like CalcMergeRule) and use only Project, Filter and Calc interfaces, which
will expand the range of their applying.
Concrete:
1. In FilterCalcMergeRule get rid of casting to LogicalCalc and LogicalFilter:
{code:java}
@Override public void onMatch(RelOptRuleCall call) {
final Filter filter = call.rel(0);
final Calc calc = call.rel(1);{code}
2. In FilterCalcMergeRule and FilterCalcMergeRule replace LogicalCalc.create
with calc.copy:
{code:java}
final Calc newCalc = calc.copy(calc.getTraitSet(), calc.getInput(),
mergedProgram);{code}
3. In ProjectCalcMergeRule replace the code:
{code:java}
if (RexOver.containsOver(program)) {
LogicalCalc projectAsCalc = LogicalCalc.create(calc, program);
call.transformTo(projectAsCalc);
return;
}{code}
with a simple one:
{code:java}
if (RexOver.containsOver(program)) {
return;
}{code}
because special rule ProjectToCalcRule convert LogicalProject to LogicalCalc.
was:
I noticed that rules ProjectCalcMergeRule and FilterCalcMergeRule
strictly dependent on LogicalCalc class (e.g. casting call.rel to
LogicalCalc, using LogicalCalc.create method and etc). I suggest
making them more generalized (like CalcMergeRule) and use only
Project, Filter and Calc interfaces, which will expand the range of
their applying.
Concrete:
1. In FilterCalcMergeRule get rid of casting to LogicalCalc and LogicalFilter:
{code:java}
@Override public void onMatch(RelOptRuleCall call) {
final Filter filter = call.rel(0);
final Calc calc = call.rel(1);{code}
2. In FilterCalcMergeRule and FilterCalcMergeRule replace
LogicalCalc.create with calc.copy:
{code:java}
final Calc newCalc = calc.copy(calc.getTraitSet(), calc.getInput(),
mergedProgram);{code}
3. In ProjectCalcMergeRule replace the code:
{code:java}
if (RexOver.containsOver(program)) {
LogicalCalc projectAsCalc = LogicalCalc.create(calc, program);
call.transformTo(projectAsCalc);
return;
}{code}
with a simple one:
{code:java}
if (RexOver.containsOver(program)) {
return;
}{code}
because special rule ProjectToCalcRule convert LogicalProject to LogicalCalc.
> Using LogicalCalc in ProjectCalcMergeRule and FilterCalcMergeRule
> -----------------------------------------------------------------
>
> Key: CALCITE-4936
> URL: https://issues.apache.org/jira/browse/CALCITE-4936
> Project: Calcite
> Issue Type: Improvement
> Components: core
> Affects Versions: 1.28.0
> Reporter: Maksim Gramin
> Priority: Major
>
> I noticed that rules ProjectCalcMergeRule and FilterCalcMergeRule strictly
> dependent on LogicalCalc class (e.g. casting call.rel to LogicalCalc, using
> LogicalCalc.create method and etc). I suggest making them more generalized
> (like CalcMergeRule) and use only Project, Filter and Calc interfaces, which
> will expand the range of their applying.
> Concrete:
> 1. In FilterCalcMergeRule get rid of casting to LogicalCalc and LogicalFilter:
> {code:java}
> @Override public void onMatch(RelOptRuleCall call) {
> final Filter filter = call.rel(0);
> final Calc calc = call.rel(1);{code}
>
> 2. In FilterCalcMergeRule and FilterCalcMergeRule replace LogicalCalc.create
> with calc.copy:
> {code:java}
> final Calc newCalc = calc.copy(calc.getTraitSet(), calc.getInput(),
> mergedProgram);{code}
>
> 3. In ProjectCalcMergeRule replace the code:
> {code:java}
> if (RexOver.containsOver(program)) {
> LogicalCalc projectAsCalc = LogicalCalc.create(calc, program);
> call.transformTo(projectAsCalc);
> return;
> }{code}
> with a simple one:
> {code:java}
> if (RexOver.containsOver(program)) {
> return;
> }{code}
> because special rule ProjectToCalcRule convert LogicalProject to LogicalCalc.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
