[jira] [Comment Edited] (CALCITE-3769) Deprecate TableScanRule

["Danny Chen (Jira)" <ji...@apache.org>]

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

Danny Chen edited comment on CALCITE-3769 at 3/1/20 3:09 AM:
-------------------------------------------------------------

The EnumerableTableScan can not handle projects/filter expressions push down correctly(there is no place/variables to hold the pushed down expressions), but the BindableTableScan did, see [1], also if the table is a ScannableTable, it expects to bind the data from the DataContext directly, there is no need for code generation ~

As the default, we set the CalciteSystemProperty.ENABLE_ENUMERABLE as true, but exclude the bindable rules, we added a EnumerableInterpreterRule.INSTANCE to convert a bindable table scan to ENUMERABLE convention.

In Calcite, the logic does not change for these tables before/after this patch, [~eolivelli] has a plan diff because they have a FilterableTable witch a EnumerableTableScan impl, which is actually wrong.

[1] https://github.com/apache/calcite/blob/eab156a88baf992644fc7b185dc7c730a49154f7/core/src/main/java/org/apache/calcite/interpreter/Bindables.java#L185


was (Author: danny0405):
The EnumerableTableScan can not handle projects/filter expressions push down correctly, but the BindableTableScan did, see [1], also if the table is a ScannableTable, it expects to bind the data from the DataContext directly, there is no need for code generation ~

As the default, we set the CalciteSystemProperty.ENABLE_ENUMERABLE as true, but exclude the bindable rules, we added a EnumerableInterpreterRule.INSTANCE to convert a bindable table scan to ENUMERABLE convention.

In Calcite, the logic does not change for these tables before/after this patch, [~eolivelli] has a plan diff because they have a FilterableTable witch a EnumerableTableScan impl, which is actually wrong.

[1] https://github.com/apache/calcite/blob/eab156a88baf992644fc7b185dc7c730a49154f7/core/src/main/java/org/apache/calcite/interpreter/Bindables.java#L185

> Deprecate TableScanRule
> -----------------------
>
>                 Key: CALCITE-3769
>                 URL: https://issues.apache.org/jira/browse/CALCITE-3769
>             Project: Calcite
>          Issue Type: Wish
>          Components: core
>    Affects Versions: 1.21.0
>            Reporter: Danny Chen
>            Assignee: Danny Chen
>            Priority: Major
>              Labels: pull-request-available
>             Fix For: 1.22.0
>
>          Time Spent: 1h 20m
>  Remaining Estimate: 0h
>
> The TableScanRule is the only planner rule that for a logical node(e.g. the table scan), its function is to pass along the cluster object and invoke the RelOptTable#toRel which is very trivial because it supplies only a simple ToRelContext that does not support expanding view/passing table hints.
> For rels that come from the sql-to-rel conversion, there is already a table conversion logic[1]. This code gives a more powerful ToRelContext that has the complete functionality.
> The only reason that I saw the meaning of existing TableScanRule is for the TableScan that comes from the RelBuilder#scan.
> So I would suggest to deprecate the TableScanRule, instead, we support translating the table directly in RelBuilder#scan,
> -We also add a new interface RelBuilder#scan(Iterable<String> tableNames, ToRelContext context), so that user can pass in a more powerful ToRelContext explicitly.- User can customize a TableScanFactory in the RelBuilder to do this.
> [1] https://github.com/apache/calcite/blob/d6fa25cd11625ad7b4b74dafbd0211c701b38d49/core/src/main/java/org/apache/calcite/sql2rel/SqlToRelConverter.java#L3498



--
This message was sent by Atlassian Jira
(v8.3.4#803005)