2021SC@SDUSC
山大软工实践hive(10)-transform方法流程结束
dispatch方法的后半部分
proc在这里只能取到FilterTransformer，它是该优化器的内部类
然后下下它调用了该类的process方法
接下来看generateClause，它同为该内部类的方法
先看注释1,2对应部分，首先看是不是or运算，如果是则看是否小于阈值（优化器初始化时的参数，应该可以修改，如下）
顺便，突然意识到，可以去搜这个路径的配置文件的相关信息，或许能知道是干什么的，在这里，找到了
虽然可以想象把一系列or统一成in，但不知道是如何效率上的提升，以及可行性
不过这里提醒我的是，HiveConf.Confvars，里面存了一堆用户可操作的配置信息
先跳过这方法后面部分，先看返回的结果
首先，这个方法要么返回null，要么返回修改后的predicate，返回后回到dispatch方法
然后同理，有则返回predicate，返回到walker的dispatch
这里往retMap放predicate存起来，这个在后面会在当nodeoutput不为null时返回所有头结点的（nd，retval）键值对，至于这个方法的return，在后面没用上，就不截图了
然后会回到generateInClause
可以理解为，输入旧predicate，如果不改变，则返回null，改变则返回newPredicate，再返回到process
如果有新的predicate，再把filter（where语句）的内容修改为新的子句就行。然后这里return null，返回到dispatch，这一段就和上面类似，不过retMap存的键值对的值都为null。最后返回到transform
return pctx；虽然这个在过程中没有什么改变，但实际改变的内容我们已经看到了：FilterOperator对应的语句的改变
也意识到，不管walker怎么花里胡哨，这里的Rule “FIL%”死了要被计算的内容：仅限一个FIL算子
也可以认为，对于各种奇怪的优化，它们会写不同的优化规则的正则表达式，只有满足条件的才会被尝试优化，这样的正则表达式表达的是算子链，代表该优化器要优化的结构。然后让walker去遍历，去看能不能优化，每查看一个算子，把Cost最小的优化的结果记录到算子本身，也可能是null代表不优化。
总结
这篇就先到这，后面有能力在回头看这个OrExpression.process后面部分
下篇可以先去看自己搜到过原理并理解了的优化器，看看它们的各部分怎么处理
