[jira] [Commented] (CALCITE-2970) Performance issue when enabling abstract converter for EnumerableConvention

["Xiening Dai (Jira)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/CALCITE-2970?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16968111#comment-16968111 ] 

Xiening Dai commented on CALCITE-2970:
--------------------------------------

Thanks [~zabetak]

I am not sure I understand the concern about RelTraitDef. In my opinion, it’s fine to keep these logics in RelTraitDef. But we just need a way to create RelNode with corresponding convention. 

[~julianhyde] mentioned that there was a proposal to add new methods in Convention interface, tracked by CALCITE-2064. I believe that would work, but I am thinking maybe we can extend RelBuilder interface to allow creating RelNode with given convention. We will add an optional parameter to specify convention. It would look like below in this particular example -

 public RelBuilder sortLimit(int offset, int fetch,
      Iterable<? extends RexNode> nodes, Convention convention)

Currently RelBuilder uses a default SortFactory which creates LogicalSort all the time. We can provide a new method to register a factory for given convention. So RelBuilder can create specific RelNode based on the convention trait.


> 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)