[
https://issues.apache.org/jira/browse/CALCITE-2970?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16962007#comment-16962007
]
jin xing commented on CALCITE-2970:
-----------------------------------
[~zabetak] [~hyuan] Thanks a lot for your shepherd and sorry for my late reply
(I missed the Jira notice from my email)
I think the root cause is as below :
1. In design&impl of {{VolcanoRuleCall#matchRecurse}}, a rule is triggered when
the root operand or child operand get matched by a new created/registered
{{RelNode. }}Relying on expansion of AbstractConverter means more fires for the
optimizing rules
2. Currently optimizing process for physical node operator like EnumerableXXX
and logical node like LogicalXXX are mixed together, thus operator with the
same semantics are optimized for multiple times. This problem is also mentioned
in https://issues.apache.org/jira/browse/CALCITE-3353 Personally I think it
might make sense to make the optimizing process into two phases – – logical
phase and physical phase
> Performance issue when enabling abstract converter for EnumerableConvention
> ---------------------------------------------------------------------------
>
> Key: CALCITE-2970
> URL: https://issues.apache.org/jira/browse/CALCITE-2970
> Project: Calcite
> Issue Type: Bug
> Components: core
> Reporter: Haisheng Yuan
> Priority: Major
> Labels: pull-request-available
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> If we enable the use of abstract converter for {{EnumerableConvention}}, by
> making {{useAbstractConvertersForConversion}} return true,
> {{JDBCTest.testJoinManyWay}} will not complete.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
