> 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. Julian On Wed, Mar 11, 2015 at 11:23 AM, Vladimir Sitnikov <[email protected]> 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
