[2023 Topic]: join-tables

[luooofan]

topic: join-tables

description: 对于 INNER JOIN 来说，on 和 where 后面的 Filter 没有什么不同，应该遵循能下推就下推的原则

[luooofan]

因为笛卡尔积比 INNER JOIN 具有更低的优先级，所以语法规则这里应该写成这个样子：

而不能写成这个样子，这种情况下是同优先级，左连接：

Commit: 83a50db61c4fdfd0ce99f5a7486ba864f5cac774 e666f49adfb8613b62da4f43bef809e38b086e27 更正：condition 应该改为 condition_list 因为 ON 条件里支持使用 AND

[luooofan]

最初的实现是比较循规蹈矩的，不动物理计划树和算子执行，ON 条件作为一个 Predicate 算子挂在 Join 算子上 c3ca2bc59b95e728e33b7f3a9685cd05dcea641b e98690ffd5286d3b3fe300bd4def0ab2a2b14d5a

本地测例超时的主要原因应该是没做算子下推，而不是更改 Join 算子的具体实现，以及预取整张右表并缓存等

想把算子下推交给 OptimizeStage 来做，但是发现在生成的 逻辑计划树 上做下推有点子复杂，需要多考虑：

• Predicate 下挂 Predicate：实现一个 PredicateMergeRewrite 的重写规则（已实现）
• Predicate 下挂 Join，Join 下挂 TableGet or Join or Predicate：拓充 PredicatePushdownRewrite 规则（未实现）

因而最终偷懒，在语义解析的时候就做了条件表达式下推 c9d9bcef53a0de1ff7aa9371ca13d4a2f27b2d66 3d3bb0857c7aba8cb72dc8cf7894c98128f7a2ff

提测后发现测例里要支持 typecast，出现了 CHARS 和 FLOATS 类型的比较，看了一下 mysql 应该是都转换成 float 进行比较 dbdb093285ab9530f8d0ef6337943d9130557508 8f5e7ef3b33d932dde38c635fa44d39eef9f0234

也补充了这个测例 8c32e696fdb14b5b217fc9c8a95292d892835d67 abc5f71746af570068fb6f10077619b78bf64c40

[luooofan]

上面每一点有两个 CommitID 分别对应 rebase 前（正常开发流程）和 rebase 后（合并解决了冲突）

rebase 后还新引入了一个 fix 的提交 1430b8eff2404ec2aa5fdc2c1a61aa7616ff1438 主要是支持新的条件表达式（lhs 和 rhs 都是 Expression）的下推

[luooofan]

PS：后来和同学交流的时候发现，既不会有笛卡尔积和 inner join 同时出现的情况，而且今年超时时间设长了以后也不需要考虑算子下推的问题