思考是技术进步的阶梯
A向B机器发送一个plan执行的时候，随着plan本身还需要发送哪些结构？
分析：
OB0.5开源版中发送了SimpleScanParam，但这个参数并不是单独发送的，而是包装在了一个ObHuskTabletScan运算符中，在CS端根据运算符中的参数重新构造子Plan。
答案：
只需要发送plan本身即可。其余要发送的内容都应该封装到operator内部。
进一步发问：
operator内部要封装什么呢？
答案：
比如，读数据超时时间。在运行时用户可以通过命令修改读超时时间，需要将新的时间让plan知晓，以便序列化到B端。
再比如，读数据的版本号。随着时间流逝plan被反复执行，plan需要携带的版本号应该要随时间变化。
这些内容的变化，都应该封装到operator内部。具体做法可以是设置一个IParamProvider()给operator，operator可以随时通过IParamProvider获得最新的数据。IParamProvider的实现比较简单，它持有整个SQL Plan运行时环境的引用，可以随时从中获得最新的参数提供给operator。这个细节不需要scheduler关心。
结论：
- 需要发送plan到B端，而不是自己裸发operator tree到远端。因为plan里面提供了一套遍历op tree（序列化）、分配operator（反序列化）的机制。相当于是一个query的管理器。
- 发送到B端的plan并不是一个全功能的plan，有精简的空间。
- plan之外并不需要传额外的东西到B端。