Daft SQL引擎中的JOIN与聚合查询问题解析

问题现象

在Daft项目中，当执行同时包含显式和隐式JOIN的SQL查询时，如果聚合函数中引用了特定表的列，查询会失败并抛出"Table not found"错误。这种查询模式在TPC-DS等标准基准测试中相当常见。

问题复现

通过以下Python代码可以复现该问题：

tbl_1 = daft.from_pydict({
    'id': [1,2,3],
    'val': ['a','b','c']
})

tbl_2 = daft.from_pydict({
    'id': [1,2,4], 
    'val2': ['x','y','z']
})

tbl_3 = daft.from_pydict({
    'id': [1,2,5],
    'val3': ['m','n','o'] 
})

daft.sql("""
select count(tbl_3.val3), tbl_2.val2
from tbl_1 
join tbl_2 on tbl_1.id = tbl_2.id, tbl_3
where tbl_1.id = tbl_3.id
group by tbl_2.val2
""").collect()

预期行为

正常情况下，SQL引擎应该能够正确处理这种混合JOIN类型的查询，并返回正确的结果。以DuckDB为例，它会返回以下结果：

┌───────────────────┬─────────┐
│ count(tbl_3.val3) │  val2   │
│       int64       │ varchar │
├───────────────────┼─────────┤
│                 1 │ y       │
│                 1 │ x       │
└───────────────────┴─────────┘

技术分析

这个问题揭示了Daft SQL引擎在处理复杂JOIN操作时的几个关键点：

1. JOIN类型混合：查询中同时使用了显式JOIN(join tbl_2 on...)和隐式JOIN(,连接tbl_3)，这种混合使用在SQL标准中是允许的，但实现起来需要特别注意作用域问题。

2. 作用域管理：在构建查询计划时，引擎需要正确管理各表的作用域，确保在聚合阶段仍然能够访问到所需的表引用。

3. 查询计划生成：问题可能出现在将SQL解析为逻辑计划，或从逻辑计划转换为物理计划的过程中，表引用信息在某个转换步骤中丢失。

4. 聚合函数处理：聚合函数中引用的列需要正确解析其所属的表，特别是在GROUP BY子句中也引用了同一表的情况下。

解决方案方向

要解决这个问题，Daft SQL引擎可能需要：

1. 改进表引用解析逻辑，确保在复杂JOIN场景下所有表引用都能正确保留。

2. 增强作用域管理，特别是在处理混合JOIN类型时，需要维护完整的表引用链。

3. 优化查询计划转换过程，确保表引用信息不会在计划转换阶段丢失。

4. 添加针对这种特定查询模式的测试用例，确保修复后不会出现回归。

总结

这个问题虽然看起来特定，但实际上反映了SQL引擎实现中常见的作用域管理和表引用处理挑战。正确处理这类查询对于保证Daft与标准SQL的兼容性，特别是对TPC-DS等基准测试的支持至关重要。