兼顾行列混合执行的优化器

由于存在行存和列存两套执行引擎，优化器在选择执行计划时有了更多的选择，其可以对比行存执行计划的Cost和列存执行计划的Cost，并使用代价最低的执行计划。
在PolarDB中，除原生MySQL的行存串行执行外，还有能够发挥多核计算能力的基于行存的Parallel Query功能。因此，实际优化器会在行存串行执行、行存Parallel Query、以及IMCI三个之中选择其一。在目前的迭代阶段，优化器按如下的流程执行：

• 执行SQL的Parse过程并生成LogicalPlan，然后调用MySQL原生优化器，并执行优化操作（join order等）。同时该阶段获得的逻辑执行计划会转给IMCI的执行计划编译模块，并尝试生成一个列存的执行计划（此处可能会被白名单拦截并回滚回行存）。
• PolarDB的Optimizer会根据行存计划，计算得出一个面向行存的执行Cost。如果此Cost超过一定阈值，则会尝试下推到IMCI执行器使用IMCI_Plan执行。
• 如果IMCI无法执行此SQL，则PolarDB会尝试编译出一个Parallel Query的执行计划并执行。如果无法生成PQ的执行计划，则说明IMCI和PQ均无法执行此SQL，则回滚回行存执行。
  上述策略是基于这样一个判断，从执行性能上进行对比：行存串行执行 < 行存并行执行 < IMCI。 对比SQL兼容性，IMCI < 行存并行执行 < 行存串行执行。但是实际情况会更加复杂，例如：某些情况下，基于行存有序索引覆盖的并行Index Join会比基于列存的Sort Merge join有更低的Cost。按照当前策略，则会选择IMCI列存执行。