[
https://issues.apache.org/jira/browse/CALCITE-2970?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17077504#comment-17077504
]
Haisheng Yuan commented on CALCITE-2970:
----------------------------------------
[~julianhyde]I got what you mean. But if the Foo creator has special physical
operator for Aggregate, why can't it have the corresponding logical operator to
represent the input RexNodes and corresponding transformation rule? In
MaxCompute we happen to have same cases for special Join, we create both
logical and physical operators from ground up and the corresponding
transformation rule. Because we believe that transformation should be done in
logical world.
So how hard would it be for Foo convention creator to create a similar logical
aggregate given that it already has the special physical aggregate?
Both are applicable, but which one is a better practice?
> 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: 12h
> 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)
