[
https://issues.apache.org/jira/browse/CALCITE-2970?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16973125#comment-16973125
]
Stamatis Zampetakis commented on CALCITE-2970:
----------------------------------------------
{quote}For example, if we have 3 conventions X, Y, and Z, then we will need
XSort, YSort, ZSort, XExchange, YExchange, ZExchange rules. Essentially the
calcite users will be duplicating the work which should have been handled by
the framework.
{quote}
Currently if we have 3 conventions we already have XSortRule, YSortRule,
ZSortRule etc. so I don't think this is a big problem. Moreover some part of
the logic could be be put in a common superclass (e.g., AbstractSortRule) and
guide the users to write properly their own extensions.
{quote}From the engineering perspective, this rule-based approach could be more
expensive to implement.
{quote}
I am not sure about this. As people mentioned above the code already exists it
is just not committed to our codebase.
{quote}To me, that's a much bigger change than just updating traitDef.convert()
{quote}
At the moment we have many ideas but none concrete proposal. I think the
next-step is somebody to take it on this issue and fire a new PR.
> 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)
