【问题标题】:How to fix postgresql update with join performance?如何使用连接性能修复 postgresql 更新?
【发布时间】:2021-04-17 10:25:54
【问题描述】:

我拥有名为 nodeways 的地理空间表。

我想使用空间连接将ways 表的end_node_id 列设置为node 表属性。两个表有大约 100K 的数据。

update ways
set
    end_node_id = n.node_id
from
    ways w
inner join
    nodes n
on
    st_endpoint(w.shape) = n.shape;

但是这个查询需要很多次。 15 分钟后,我停止了查询。这个操作有性能查询吗?

更新说明:

Update on ways w (cost=0.00..669909619.43 rows=24567397 width=576)  
->  Nested Loop  (cost=0.00..669909619.43 rows=24567397 width=576)
          Join Filter: (st_endpoint(w.shape) = n.shape)
          ->  Seq Scan on ways w (cost=0.00..8960.61 rows=120161 width=564)
          ->  Materialize  (cost=0.00..12200.81 rows=204454 width=52)
                        ->  Seq Scan on nodes n  (cost=0.00..9181.54 rows=204454 width=52)

【问题讨论】:

    标签: sql postgresql postgis spatial spatial-query


    【解决方案1】:

    不要在from 子句中包含ways!这不符合您的预期。大概,你想要:

    update ways w
        set end_node_id = n.node_id
    from nodes n
    where st_endpoint(w.shape) = n.shape;
    

    在您的公式中,update 中的waysfrom 中的ways 的引用不同。因此,您的代码正在创建笛卡尔积——这无疑会减慢处理速度。请注意,这与 SQL Server 的行为不同,后者具有相似的语法。

    【讨论】:

    • 我尝试了这个解决方案,但它正在执行 1 小时,尚未编译。
    • @barteloma 。 . .我怀疑nodes 很大。这仍然是在waysnodes 之间进行笛卡尔积。如果您需要加快速度,您可能需要一些特定的地理索引。
    • 我已经用解释更新了帖子。但是我不太明白解释。这两个表都有 100K 数据,并且都有空间索引。
    • @barteloma 。 . . ways 中的每一行都必须与 nodes 中的 100,000 行进行比较。唉,这需要一段时间。
    • 是的,但是如果我设置日期过滤器where created_at::date=current_date 查询需要很长时间。
    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2015-07-29
    • 2014-01-27
    • 2016-02-04
    • 2023-03-05
    相关资源
    最近更新 更多