PostgreSQL - OSM数据上的表连接非常慢



我在创建表的连接时遇到问题。查询将永久运行。我在一个表格中打开了自行车路线的街道地图,其中包含所有属性。

Table planet_osm_line
osm_id bigint,
route text,
name text,
network text,
osmc_color text,
reversed text,
state text,
"instance:cycle" text,
"relation:id" text,
ref text,
description text,
distance text,
tags hstore,
way geometry(LineString,900913)

有些线是重复的(单程上有 2 条或更多条路线),所以我将唯一的线过滤到另一个表中,并尝试将它们与planet_osm_line中的数据合并:

DROP TABLE  IF EXISTS  public.bicycle_merge;
CREATE TABLE public.bicycle_merge AS
WITH singleRow as ( 
   select count(way), way
   from planet_osm_line 
   WHERE route IN ('bicycle')
   group by way
   having count(way) = 1
)
SELECT P.*
FROM planet_osm_line P
JOIN singleRow S
  ON P.way = S.way
;

此查询将永远运行。原谅我的新手问题,但我做错了什么?

"Nested Loop  (cost=28767.43..172920474.87 rows=5892712 width=335)"
"  Join Filter: (p.way = s.way)"
"  CTE singlerow"
"    ->  GroupAggregate  (cost=27040.24..28767.43 rows=76764 width=218)"
"          Filter: (count(planet_osm_line1.way) = 1)"
"          ->  Sort  (cost=27040.24..27232.15 rows=76764 width=218)"
"                Sort Key: planet_osm_line1.way"
"                ->  Seq Scan on planet_osm_line1  (cost=0.00..4543.55     rows=76764 width=218)"

Planet_osm_line表大约有 70.000 行。独特的几何形状约为 50.000。此查询适用于一小部分数据,但现在我正在处理整个国家(波兰)的自行车路线。提前非常感谢!

您正在连接两个普通几何图形。这意味着您正在对所有可能的匹配项之间的几何图形进行二进制比较,逐字节比较。这确实需要大量的时间。在您的EXPLAIN ANALYZE中,CTE 的成本为 28,767;联接是 6,000 倍

相反,您应该测试两个几何图形是否相互接触(由于OSM已正确进行地理编码,因此您可以假设没有线相交):

WITH singleRow AS ( 
   SELECT count(way), way
   FROM planet_osm_line 
   WHERE route IN ('bicycle')
   GROUP BY way
   HAVING count(way) = 1
)
SELECT P.*
FROM planet_osm_line P
JOIN singleRow S ON ST_Contains(P.way, S.way);

在像这样检索的行集上,您可以应用函数 ST_MakeLine() 将较小的行实际合并为一行。

最新更新