【问题标题】:Merge join in PostgreSQL performs sort on indexed columnPostgreSQL 中的合并连接对索引列执行排序
【发布时间】:2022-11-02 13:41:37
【问题描述】:

我正在尝试在 postgresql 中优化以下查询

    SELECT ci.country_id, ci.ci_id,ci.name
    FROM customer c
        INNER JOIN address a ON c.a_id = a.a_id
        INNER JOIN city ci ON ci.ci_id = a.ci_id

customer.a_id、address.a_id、city.ci_id 和 address.ci_id 列都有一个 btree 索引。 我想使用合并连接而不是哈希连接,因为我读到哈希连接并没有真正使用索引,所以我用Set enable_hashjoin=off 关闭了哈希连接。

我的查询现在根据使用合并联接的查询计划,但它始终在合并联接之前执行快速排序。我知道对于合并连接,需要对列进行排序,但它们应该已经通过索引进行了排序。有没有办法强制 Postgres 使用索引而不是执行排序?

【问题讨论】:

  • 为什么你认为合并连接会更有效?您正在从所有表中读取所有行,这不是索引会有所帮助的情况
  • 您能否分享一下这个查询的解释(分析、详细、缓冲区、成本)的结果?
  • 所有表的表大小都不是很大,所以我想知道是否可能为哈希连接构建哈希表比使用合并连接需要更多时间,即使合并连接不快我仍然对为什么它不感兴趣使用排序索引。我在问题中添加了查询计划的图片
  • 执行计划最好共享为formatted text。为确保保留计划的缩进,edit 您的问题,粘贴文本,然后将``` 放在计划之前的一行和计划之后的一行。请使用合并连接分享计划使用哈希连接的计划。
  • 查询计划很难阅读,但我看到的是花费的时间:大约 2 毫秒。当 2 毫秒对您来说已经是一个问题时,您在寻找什么样的性能?

标签: postgresql query-optimization


【解决方案1】:

您正在加入三个表。它使用两个合并连接来做到这一点,一个合并连接的输出是另一个的输入。中间表是使用两个不同的列连接的,但它不能同时在两个不同的列上排序,所以如果你只打算使用合并连接,你至少需要一个排序。

整个事情看起来毫无意义,因为查询已经非常快了,你为什么关心它是否使用哈希连接?

【讨论】:

    猜你喜欢
    • 2013-07-21
    • 1970-01-01
    • 2016-12-29
    • 2016-01-01
    • 1970-01-01
    • 2011-07-09
    • 2014-03-30
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多