【问题标题】:Optimizing OUTER JOIN queries using filters from WHERE clause.(Query Planner)使用 WHERE 子句中的过滤器优化 OUTER JOIN 查询。(查询规划器)
【发布时间】:2020-05-13 10:59:15
【问题描述】:

我正在编写一个分布式 SQL 查询计划器(查询引擎)。数据将从涉及网络 I/O 的 RDBMS(PostgreSQL) 节点获取。

我想优化 JOIN 查询。

执行的逻辑顺序是:

  1. 做JOIN(利用ON子句)
  2. 对连接的结果应用 WHERE 子句。

我正在考虑先应用过滤器(特定于表的 WHERE 子句)本身,然后再加入。 在什么情况下会导致错误的结果?


例子:

SELECT * 
FROM tableA 
LEFT JOIN tableB ON(tableA.col1 = tableB.col1) 
LEFT JOIN tableC ON(tableB.col2 = tableC.col1)
WHERE tableA.colY < 100 AND tableB.colX > 50 

逻辑执行:

  1. joinResult = (tableA left join tableB ON() ) left join tableC ON()
  2. 使用给定的 WHERE 子句过滤 joinResult。

建议执行:

  1. filteredA = tableA WHERE tableA.colY

    filteredB = tableB WHERE tableB.colX > 50

  2. 结果 = (filteredA left join filteredB ON(..))left join tableC ON(..)

我可以像这样优化任何查询吗?那就是先过滤表,然后在上面应用连接。

编辑: 有些人在谈论这个具体的例子时感到困惑和谈论。我不是在谈论这个特定的示例查询,我正在编写一个查询计划器,我想处理所有类型的查询

请注意,每个表都被分片存储在不同的机器上,当前的执行模型是获取每个表然后在本地进行连接。因此,如果我在获取之前应用 WHERE 过滤器,那就更好了。

【问题讨论】:

  • 您的 where 子句正在将第一个 left join 转换为内部连接。
  • 这只是一个例子,WHERE 子句可能根本不存在。反正我已经编辑过了
  • Logical Order of Execution is: 错误。没有逻辑顺序。只要结果正确,什么都可以。
  • @Insaf:这是语句的解析顺序,而不是实际的执行顺序
  • 如果你正在编写自己的 DBMS,那么这与 PostgreSQL 有什么关系?

标签: sql postgresql optimization sql-optimization query-planner


【解决方案1】:

这其实是一个复杂的话题。

在某些情况下,我们可以过滤表格。我们还可以重新排序外部连接,然后将过滤器 quals 推入内部。

我正在阅读有关此的研究论文,但我还没有完成(可能也没有完成)。

所以现在,对于那些正在寻找答案的人,您可能可以阅读这篇研究论文,尤其是第 2.2 节。 http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.43.2531&rep=rep1&type=pdf


目前,我依赖 PostgreSQL 的规划器并获取其输出并根据我的要求重构查询。

【讨论】:

    猜你喜欢
    • 2016-06-01
    • 1970-01-01
    • 2017-01-16
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2017-06-08
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多