calcite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vladimir Sitnikov <sitnikov.vladi...@gmail.com>
Subject Re: JdbcSort not used in plan.
Date Wed, 11 Mar 2015 17:33:29 GMT
> Informally, we would choose the one with the "more efficient convention".

As you know, I would prefer enumerable over.... stop.

> allows us to achieve this fairly simply.

1) I am not sure if JdbcProject==EnumerableProject*0.8 properly
correlates with actual response times.
For instance, JdbcProject(JdbcTableScan) costs _less_ than a simple
JdbcTableScan.
In other words, it is a bit strange why adding JdbcProject increases cost.
In exactly the same way, a filter executed at jdbc side reduces the
cost of jdbc table scan.

2) JdbcToEnumerableConverter, on contrary, uses
super.computeSelfCost(planner).multiplyBy(.1).
I believe the cost of JdbcToEnumerable should depend on the both
number of rows and columns.

3) It is a bit odd that the cost is based on the number of "rows". I
do understand there should be a single "double" that is used to
compare cost, however it is not that good to assume that cost of "jdbc
scan" is proportional to the number of rows.
The cost depends on _filters_, since when Calcite pushes a filter down
to jdbc, the database can use index to get the required row, so the
cost is much less than a cost of a full table scan.


Well, that was a bit long.
I suggest:
1) Revise costing functions. Include column count where required
2) Probably start a set of planner test cases that assert cost-based decisions.
3) In far far future, we might want to know "indexes available at jdbc
side", so we can better assess the available indexed paths.

Vladimir

Mime
View raw message