OptD项目中的多谓词连接投影上拉规则问题解析

OptD项目中的多谓词连接投影上拉规则问题解析

optd-original CMU-DB's Cascades optimizer framework 项目地址: https://gitcode.com/gh_mirrors/op/optd-original

在数据库查询优化器OptD项目中，我们发现了一个关于投影上拉规则在处理多谓词连接时的技术问题。本文将深入分析该问题的技术背景、具体表现以及解决方案。

问题背景

在查询优化过程中，投影上拉(Pull Up Projection)是一种常见的优化技术，其目的是将投影操作尽可能地向查询树的顶部移动，从而减少后续操作需要处理的数据量。在OptD项目中，这一优化规则在处理带有多个连接谓词的连接操作时出现了问题。

技术细节分析

问题的根源在于OptD内部对连接谓词的不同处理方式：

1. 单谓词连接：当连接条件只有一个谓词时，系统将其表示为二元操作表达式(BinOpExpr)，这种结构可以直接被投影上拉规则处理。

2. 多谓词连接：当连接条件包含多个谓词时，系统会使用逻辑操作(LogOp)将这些谓词组合起来，具体表现为LogOp(And)结构。这种结构将多个谓词存储在ExprList中，而ExprList的类型是List，这与投影上拉规则预期的表达式类型不匹配。

问题表现

在代码实现层面，问题具体表现为：

1. 在数据融合桥接层(optd-datafusion-bridge)，多谓词连接被转换为LogOp(And)结构。

2. 在投影上拉规则实现中，代码假设连接条件总是BinOpExpr类型，直接对其子节点调用unwrap()方法。

3. 当遇到LogOp(And)结构时，由于子节点是ExprList(List类型)而非表达式，导致unwrap()调用失败，引发panic。

解决方案探讨

针对这一问题，社区提出了几种可能的解决方案：

1. 将ExprList归类为表达式：修改类型系统，使列表也能被视为表达式的一种。这种方案简单直接，但需要考虑ExprList是否仅用于存储表达式。

2. 编写辅助函数：开发能够同时处理列表和表达式的辅助函数，使投影上拉规则能够处理两种结构。

3. 类型系统重构：建议将ExprList(用于投影列表)和ExprVarChildren分开处理，可能需要从RelNodeTyp中移除list_typ。

最终解决方案

经过讨论，项目采用了最直接的解决方案：修改LogOpExpr的实现，使其直接使用Vec 作为子节点，而不是ExprList。这一改动使得：

• 保持了类型系统的简洁性
• 无需引入额外的辅助函数
• 解决了投影上拉规则的处理问题

技术启示

这一问题的解决过程为我们提供了几个重要的技术启示：

1. 类型系统设计需要考虑实际使用场景，特别是边界情况。

2. 优化规则的实现需要对各种可能的输入结构保持鲁棒性。

3. 在数据库优化器开发中，表达式树的表示方式会直接影响优化规则的实现复杂度。

通过这个案例，我们看到了在查询优化器开发中类型系统设计与优化规则实现之间的紧密联系，以及如何通过合理的架构设计来解决这类跨模块的技术问题。

optd-original CMU-DB's Cascades optimizer framework 项目地址: https://gitcode.com/gh_mirrors/op/optd-original