Optd项目中Join谓词处理问题的分析与解决

Optd项目中Join谓词处理问题的分析与解决

在数据库查询优化器Optd项目中，开发团队发现了一个关于Join操作谓词处理的bug。这个问题涉及到数据融合(DataFusion)逻辑优化器未启用时的特殊场景，导致Join条件被错误地存储在了filter字段而非on字段中。

问题背景

在SQL查询中，Join操作通常通过ON子句指定连接条件。例如：

SELECT * FROM t1 JOIN t2 ON t1.t1v1 = t2.t2v1

在Optd项目的实现中，当DataFusion逻辑优化器未启用时，系统会将Join谓词存储在filter字段而非预期的on字段中。这种不一致性导致了Equal条件连接操作的失败，因为系统没有正确处理这种特殊情况。

问题表现

当执行上述Join查询时，系统会输出如下的执行计划：

Join.on: []
Join.filter: Some(
    BinaryExpr(
        BinaryExpr {
            left: Column(
                Column {
                    relation: Some(
                        Bare {
                            table: "t1",
                        },
                    ),
                    name: "t1v1",
                },
            ),
            op: Eq,
            right: Column(
                Column {
                    relation: Some(
                        Bare {
                            table: "t2",
                        },
                    ),
                    name: "t2v1",
                },
            ),
        },
    ),
)

随后系统会抛出panic错误，提示不支持的Join filter类型。

技术分析

这个问题的本质在于Optd项目对Join条件的处理逻辑不够全面。在正常情况下，Join条件应该存储在on字段中，但当某些优化器被禁用时，条件可能会被放入filter字段。系统当前的实现没有考虑到这种特殊情况，导致无法正确处理Equal条件的Join操作。

从技术实现角度看，BinaryExpr结构体表示了一个二元表达式，包含左右操作数和操作符。在这个例子中，操作符是Eq(等于)，左右操作数分别是来自两个表的列。

解决方案

针对这个问题，开发团队提出了两种解决方案思路：

1. 使用LogOp::And操作将filter条件转换为Join条件。这种方法利用了逻辑与操作来整合多个条件，保持了查询语义的一致性。

2. 修改Join条件的处理逻辑，使其能够同时处理on字段和filter字段中的条件。这种方法更加全面，能够适应不同的优化器配置情况。

最终，开发团队选择了第二种方案，通过修改Join条件的处理逻辑来彻底解决这个问题。这个修改使得系统能够正确处理所有情况下的Join条件，无论它们存储在on字段还是filter字段中。

技术意义

这个问题的解决不仅修复了一个具体的bug，更重要的是完善了Optd项目对Join操作的处理能力。在查询优化器的实现中，能够正确处理各种情况下的Join条件对于保证查询结果的正确性至关重要。

此外，这个案例也展示了数据库系统中查询计划表示的重要性。同一个逻辑操作(如Join)可能有多种物理表示方式，系统需要能够处理这些不同的表示形式，才能保证在各种配置下都能正确工作。

通过解决这个问题，Optd项目在处理复杂查询时的稳定性和可靠性得到了提升，为后续的功能开发和性能优化奠定了更坚实的基础。