calcite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Julian Hyde <>
Subject Re: JdbcSort not used in plan.
Date Wed, 11 Mar 2015 18:50:14 GMT
> As you know, I would prefer enumerable over.... stop.

Yeah, we agree to disagree. We should use pluggable metadata providers
so you can use one that says that enumerable is totally awesome and
Jacques can use one that says enumerable sucks. :)

My opinion of costs is the same as Richard Feynmann's opinion of
physical theories -- it's pointless to argue whether they are correct,
but we should instead judge them by whether they achieve the desired
result with as little fuss as possible.

So, feel free to revise the cost model. Write tests as you do it. I'll
only complain if the tests start producing dumb plans (that is, dumber
than they do now).

I would advise you not to make the cost model more complicated than it
needs to be. Every extra variable (e.g. column count) you add is a new
opportunity for something to go wrong.

Can you log your findings in a jira case? It's all good stuff.

And by the way, we have diverged from the original intend of this
thread. Jiunn Jye Ng said that his query failed to use JdbcSort even
when he had hacked the cost model. That seems to be a more tractible
and pressing issue.


On Wed, Mar 11, 2015 at 11:23 AM, Vladimir Sitnikov
<> wrote:
> More findings:
> JdbcJoin.getRows diverges from Join.getRows, so EnumerableJoin has
> different cost from JdbcJoin.
> org.apache.calcite.rel.core.Project#computeSelfCost uses dRows *
> exps.size() in the CPU part of the cost, however VolcanoPlanner just
> ignores CPU part of the cost.
> We might want start adding "per cell" cost cpu factor, so the cost of
> project would be nRows + nRows*nExps*per_cell_cost_factor
> Vladimir

View raw message