在 Apache Cloudberry 中，优化器、规划器（planner）和执行器对同一条查询持有不同的抽象。当这些抽象之间出现分歧时，即使是简单的查询也可能引发严重的故障。 本次演讲分享一个涉及复制表（replicated table）上公共表表达式（CTE）共享扫描（Shared Scan）的真实 bug。当此类 CTE 被作为标量子查询多次引用时，查询可能无限期挂起，或报出"could not open existing temporary file"之类的错误。 根本原因在于逻辑执行与物理执行之间的错配：标量 SubPlan 向优化器隐藏了依赖关系，导致 slice 分配不正确，破坏了生产者—消费者的局部性。 在本次演讲中，我将梳理几种可选的修复方案，并解释每种方案是如何尝试解决这一问题的。我们会深入优化器内部，理解这个 bug 为何会产生、不同修复方案如何改变执行拓扑，以及为什么其中一些方案——尽管可行——却无法作为最终方案被接受。 有些修复会引入细微的回归、改变计划形态，或被迫回退到 Postgres 优化器，这凸显了在不破坏全局行为的前提下做局部改进的困难。 本次演讲展示了看似简单的查询模式如何暴露优化器与执行器之间深层的不一致——以及为什么修复这类问题往往需要在权衡中抉择，而非寻找一个唯一"正确"的答案。
