【问题标题】:Slow update with ST_Contains()使用 ST_Contains() 缓慢更新
【发布时间】:2013-04-03 18:36:37
【问题描述】:
UPDATE tbl
SET city=s.city_name
FROM shp AS s
WHERE
ST_CONTAINS(s.city_geom,geom);

使用上面的代码,我可以将确切的城市添加到 GPS 点。 它在 5000 万行上运行大约 45-50 分钟。 “城市”表中大约有 4000 个城市需要检查。

我有另一个形状文件,其中包含给定国家/地区的 19 个县(只有 1 个国家/地区)。 将县添加到点大约需要 1.5 小时。

我有一个包含 52 个欧盟国家的第三个形状文件。 它使用相同的 sql 查询运行了将近 25 小时。

每个表都有geom索引,比如:

CREATE INDEX idx_txt_geom ON txt USING GIST(geom);

:为什么只检查几个多边形就这么慢?

解释分析:

Update  (cost=0.00..324.85 rows=1 width=286) (actual time=353.932..353.932 rows=0 loops=1)
  Buffers: shared hit=73090 read=1
  ->  Nested Loop  (cost=0.00..324.85 rows=1 width=286) (actual time=0.544..341.936 rows=471 loops=1)
        Join Filter: _st_contains(s.geom, prob.geom)
        Buffers: shared hit=69985
        ->  Seq Scan on world s  (cost=0.00..83.44 rows=244 width=48) (actual time=0.009..0.319 rows=244 loops=1)
              Buffers: shared hit=81
        ->  Index Scan using idx_prob_geom on prob  (cost=0.00..0.73 rows=1 width=270) (actual time=0.003..0.024 rows=9 loops=244)
              Index Cond: (s.geom && prob.geom)
              Buffers: shared hit=533
Total runtime: 354.640 ms

【问题讨论】:

  • 添加EXPLAIN 以显示它是否使用索引。
  • explain (buffers, analyze) 请按postgresql-performance
  • 我对一个小数据样本进行了解释分析。

标签: postgresql postgis postgresql-performance


【解决方案1】:

ST_CONTAINS 不能使用索引。试试这个:

UPDATE tbl
SET city=s.city_name
FROM shp AS s
WHERE
(geom && s.city_geom) and ST_CONTAINS(s.city_geom,geom);

&& 检查边界框并使用索引。

【讨论】:

  • 在一个小数据样本上也试过这个,它没有变得更快。
  • 看来,ST_CONTAINS 可以使用索引...然后尝试运行 VACUUM ANALYZE。
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 2013-03-31
  • 2013-11-27
  • 2017-10-29
  • 1970-01-01
  • 2012-01-27
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多