[
https://issues.apache.org/jira/browse/CALCITE-4290?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17220949#comment-17220949
]
Roman Churganov edited comment on CALCITE-4290 at 10/26/20, 11:09 PM:
----------------------------------------------------------------------
Thanks for the resources. Using column width in the cost model would not solve
a problem, since the cost calculated as nodeCost + childNodesCost, so if I
will wrap a TableScan in Project to limit column count, any Project only adds
more cost to the house. Correct me if I am wrong. Actually, we solved a
problem using additional plan transformation after the physical plan ready, for
example, SELECT {{CHAR_LENGTH(c3) FROM t}}, we have a query where we need only
one column c3 to be derived by subquery since the CHAR_LENGTH function not
supported on the target database and cannot be pushed to the subquery, Calcite
will make a subquery like SELECT * FROM t:
{{Original plan:}}
{{ EnumerableProject(EXPR$0=[CHAR_LENGTH($3)])}}
{{ JdbcToEnumerableConverter}}
{{ TableScan(table=[[t]])}}
{{After transformation:}}
{{ EnumerableProject(EXPR$0=[CHAR_LENGTH($3)])}}
EnumerableCalc(EXPR#0=[\\{inputs}], EXPR#1=[null:VARCHAR]],
$0=[$t1], $1=[$t1], $2=[$t1], $3=[$t0], $4=[$t1], $5=[$t1])
{{ }}{{JdbcToEnumerableConverter}}
{{ Project(EXPR$0=[$3])}}
{{ TableScan(table=[[t]])}}
was (Author: rrrrrr111):
Thanks for the resources. Using column width in the cost model would not solve
a problem, since the cost calculated as nodeCost + childNodesCost, so if I
will wrap a TableScan in Project to limit column count, any Project only adds
more cost to the house. Correct me if I am wrong. Actually, we solved a
problem using additional plan transformation after the physical plan ready, for
example SELECT {{CHAR_LENGTH(c3) FROM t}} , we have a query where we need only
one column value c3 need to be derived by subquery, since the {{CHAR_LENGTH
}}function not supported on the target database and cannot be pushed to
subquery, Calcite will make a subquery like SELECT * FROM t:
{{Original plan:}}
{{ EnumerableProject(EXPR$0=[CHAR_LENGTH($3)])}}
{{ JdbcToEnumerableConverter}}
{{ TableScan(table=[[t]])}}
{{After transformation:}}
{{ EnumerableProject(EXPR$0=[CHAR_LENGTH($3)])}}
EnumerableCalc(EXPR#0=[\\{inputs}], EXPR#1=[null:VARCHAR]],
$0=[$t1], $1=[$t1], $2=[$t1], $3=[$t0], $4=[$t1], $5=[$t1])
{{ }}{{JdbcToEnumerableConverter}}
{{ Project(EXPR$0=[$3])}}
{{ TableScan(table=[[t]])}}
> Not optimal subqueries due to a "*" in them
> -------------------------------------------
>
> Key: CALCITE-4290
> URL: https://issues.apache.org/jira/browse/CALCITE-4290
> Project: Calcite
> Issue Type: Bug
> Components: jdbc-adapter
> Affects Versions: 1.25.0
> Reporter: Roman Churganov
> Priority: Major
>
> Run a query which should be distributed into sub-queries onto multiple
> schemas through JDBC adapter, for example
> select ft.id, ft.c11, tt.c41 from sch1.foo ft join sch2.tab tt on
> ft.id = tt.id
> Calcite will make two sub-queries like SELECT * FROM "TAB" ORDER BY "ID" and
> SELECT * FROM "FOO" ORDER BY "ID" which are not optimal due to an excessive
> columns data requested
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
