[
https://issues.apache.org/jira/browse/CALCITE-2970?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17099212#comment-17099212
]
Xiening Dai commented on CALCITE-2970:
--------------------------------------
{quote}
The example outlined by Xiening Dai previously demonstrates that we may need to
obtain a builder from a call and switch it to generate Enumerable operators but
which rules need this kind of transformation?
{quote}
A quick example today would be ProjectMerge rule which always creates
LogcialProject regardless the convention of the original project nodes got
merged. We could have do -
{code}
RelBuilder builder = node.getConvention().transformRelBuilder(call.builder());
{code}
The approach you proposed would work but still have the issues I mentioned -
1. Cannot support sub-classing. There's no way to create a sub-classed
RelBuilder since particular type of RelBuilder doesn't necessarily tie with a
particular convention. Convention#getRelFactory() doesn't know how to create a
sub-class of RelBuilder.
2. A new object created every time. For example, ProjectMerge rule can be fired
tens of thousands of times. Aside from the class initialization overhead, there
are a lot more objects in the heap to track and garbage collect. Why do you
want to pay this cost without seeing an obvious benefit?
Thanks.
> 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: 18h 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)
