Calcite分析 -- Cost
Calcite Version：1.26.0
初始的cost
加入RelNode的时候，需要更新subset的cost
RelSubset
找出traits想匹配的subsets，
然后逐一更新cost，
propagateCostImprovements0
getCost
叠加所有input的cost，所以input的cost是inf，按叠加后也是inf
这里注意，Convention为None的时候，cost就是inf，所以只有当RelNode转成Enumerable后，才有cost
所以只有TopDown到叶子节点，才会生成并更新subset的bestcost，因为没有input的cost是inf了
nonCumulativeCostHandler这里是codegen产生的，
RelMetadataProvider
RelOptCluster-> setMetadataProvider(DefaultRelMetadataProvider.INSTANCE);
这步就是在初始化的时候将JaninoRelMetadataProvider的provider，设置成DefaultRelMetadataProvider.INSTANCE
DefaultRelMetadataProvider
其中，RelMdPercentageOriginalRows
这里包含了对于getNonCumulativeCost的实现，
下面看下如果Codegen的，
前面的revise，调用到create，
创建Key，包含Def和provider
Def，获取哪个method的handle
provide，包含所有method和实现类的对应关系
Handles是个cache，
cache中没有，调用load3创建，
前面生成handle的name，和相应的provider
最终通过，字符串拼接，codegen出来的代码主要是，
搞了这么多，其实就是为了为不同的RelNode生成不同的处理函数，避免手写switch case。
private org.apache.calcite.plan.RelOptCost getNonCumulativeCost_( org.apache.calcite.rel.RelNode r, org.apache.calcite.rel.metadata.RelMetadataQuery mq) { switch (relClasses.indexOf(r.getClass())) { default: return provider0.getNonCumulativeCost((org.apache.calcite.rel.RelNode) r, mq); case 3: return getNonCumulativeCost(((org.apache.calcite.plan.hep.HepRelVertex) r).getCurrentRel(), mq); case -1: throw new org.apache.calcite.rel.metadata.JaninoRelMetadataProvider$NoHandler(r.getClass()); } }
看下这个的codegen，更明显一些，为不同的重载函数，
private java.lang.Double getRowCount_( org.apache.calcite.rel.RelNode r, org.apache.calcite.rel.metadata.RelMetadataQuery mq) { switch (relClasses.indexOf(r.getClass())) { default: return provider0.getRowCount((org.apache.calcite.rel.RelNode) r, mq); case 2: return provider0.getRowCount((org.apache.calcite.plan.volcano.RelSubset) r, mq); case 3: return getRowCount(((org.apache.calcite.plan.hep.HepRelVertex) r).getCurrentRel(), mq); case 4: case 5: case 9: case 17: case 21: case 22: case 23: case 29: case 33: case 41: case 45: case 46: case 47: return provider0.getRowCount((org.apache.calcite.rel.SingleRel) r, mq); case 6: case 24: case 30: return provider0.getRowCount((org.apache.calcite.rel.core.Aggregate) r, mq); case 7: case 31: return provider0.getRowCount((org.apache.calcite.rel.core.Calc) r, mq); case 8: case 32: return provider0.getRowCount((org.apache.calcite.rel.core.Correlate) r, mq); case 10: case 25: case 34: return provider0.getRowCount((org.apache.calcite.rel.core.Filter) r, mq); case 11: case 35: return provider0.getRowCount((org.apache.calcite.rel.core.Intersect) r, mq); case 12: case 27: case 36: case 48: return provider0.getRowCount((org.apache.calcite.rel.core.Join) r, mq); case 13: case 37: return provider0.getRowCount((org.apache.calcite.rel.core.Minus) r, mq); case 14: case 26: case 38: return provider0.getRowCount((org.apache.calcite.rel.core.Project) r, mq); case 15: case 39: return provider0.getRowCount((org.apache.calcite.rel.core.Sort) r, mq); case 18: case 28: case 42: return provider0.getRowCount((org.apache.calcite.rel.core.TableScan) r, mq); case 19: case 43: return provider0.getRowCount((org.apache.calcite.rel.core.Union) r, mq); case 20: case 44: return provider0.getRowCount((org.apache.calcite.rel.core.Values) r, mq); case -1: throw new org.apache.calcite.rel.metadata.JaninoRelMetadataProvider$NoHandler(r.getClass()); } }
computeSelfCost
getNonCumulativeCost最终还是调用到computeSelfCost
所以cost，取决于不同的RelNode的computeSelfCost实现
这里注意，AbstractConverter的cost也是inf
比如对于Filter，computeSelfCost
getRowCount又是要codegen，调用到RelMDRowCount，
propagateCostImprovements0
cost传播的过程，
rel#31:EnumerableTableScan.ENUMERABLE.[](table=[CATALOG, SALES, EMP])的subset是，rel#32:RelSubset#0.ENUMERABLE.[]
getParents的逻辑，是找parents里面以rel#32为input的，如果不是以rel#32为input，也没有理由propagate
对于每个parent，取所在RelSet的所有subsets，和parent的traits比较，相符合的放入队列
对于parent，不光需要propagate他的subset，同一个set中traits符合的都需要propagate
这个理论上也不会有一样的subset，所以看着是废话，
但是这里satisfies的逻辑，不是完全一样，只需要startwith就行，
所以对于，rel#29:RelSubset#0.ENUMERABLE.[3 DESC-nulls-last]，rel#32:RelSubset#0.ENUMERABLE.[]也是satisfies的
所以这里结果是，有点出乎意料，
当前，rel#32:RelSubset#0.ENUMERABLE.[]完成propagate，继续
完成rel#29和rel#25的propagate，
注意上面33，34虽然也对32创建了propagate，但是都没有31cost低，所以32的best还是31
继续propagate，
直到root，完成propagate，
注意这里的Root是Subset，应该说经过一遍Register后，Plan上说有的节点都变成SubSet，为何要将RelNode变成SubSet？
因为在优化过程中，随着cost的变化，SubSet虽然不变，但是作为best的RelNode的是可以变的
为什么不用RelSet作为Root？RelSet只是个理论上的概念，现实中的数据都是带物理属性的，比如convention
这里有个设计比较麻烦？
找Subset所关联的RelNode是很麻烦的，要到Set.Rels里面去找和subset的traits匹配的所有RelNode
RelSet中所包含的Relnode，虽然在逻辑上是等价的，但是在物理上确实属于不同的subset
在物理属性上，Root的物理属性是最关键的，因为这个是最终输出给用户的，底下的所有的物理属性都是由这个决定的
所以在subset的state如果是Required，是个很强的约束，无论其他的subset是怎么样的traits，但最终还是要通过converter转换成满足required
所以这里的cost的propagate，就是沿着bottomup，一路更新cost和并试图去更新subset的best
这也是cost model，通过rule增加不同算子的目的，所以在addRelToSet后，都会试图去更新cost。
prune
subset.upperBound，表示这个group的cost的上限，初始化的时候是inf
当前产生bestcost的时候，会将bestcost赋值给upperBound，当有一个plan产生这样的cost，那么大于这个cost的plan都可以ignore了
onProduce也会被更新，
startOptimize时，也会调整upperBound的值，
OptimizeInput1
这里的mExpr表示待优化的算子，group表示mExpr属于的真正被优化的subset
这个mExpr是否有优化的价值，取决于当前subset.upperBound - cost(mExpr) 是否大于0
意思是如果mExpr本身的cost都已经大于subset.upperBound，那么该mExpr的input就没有继续优化的价值了
下面的例子中，
group.upperBound是rel#31:EnumerableTableScan.ENUMERABLE.[](table=[CATALOG, SALES, EMP])的bestcost
这里mExpr，rel#33:EnumerableSort.ENUMERABLE.[3](input=RelSubset#32,sort0=$3,dir0=ASC)本身的cost已经大于这个upperBound，所以没有比较继续OptimizeInput了
对于OptimizeInputs，prune的逻辑复杂些，
OptimizeGroup
首先，OptimizeGroup的参数upperBound，
在root首次调用OptimizeGroup的时候，传入的是inf
在OptimizeInput调用OptimizeGroup的时候，传入的是upperForInput，合乎情理
两种情况下，都会终止继续优化该group，一种是该group已经完成优化了；一种是在优化中，但是传入的upperForInput比现有的group.upperBound小
