ST_Intersection 느린 쿼리


11

두 레이어 사이의 교차를 수행하려고합니다.

  1. 일부 도로를 나타내는 폴리 라인 레이어 (~ 5500 행)
  2. 다양한 관심 지점 주위에서 불규칙한 모양의 버퍼를 나타내는 다각형 레이어 (~ 47,000 행)

궁극적으로, 내가하려고하는 것은 폴리 라인을 이러한 많은 (때로는 겹치는) 버퍼에 클립 한 다음 각 버퍼에 포함 된 도로의 총 길이를 요약하는 것입니다.

문제는 상황이 느리게 실행되고 있다는 것입니다. 시간이 얼마나 걸리는지 잘 모르겠지만 34 시간이 지난 후에 쿼리가 중단되었습니다. 누군가 내 SQL 쿼리에서 실수를 한 부분을 지적하거나 더 나은 방법을 지적 할 수 있기를 바랍니다.

CREATE TABLE clip_roads AS

SELECT 
  ST_Intersection(b.the_geom, z.the_geom) AS clip_geom,
  b.*

FROM 
  public."roads" b, 
  public."buffer1KM" z

WHERE ST_Intersects(b.the_geom, z.the_geom);


CREATE INDEX "clip_roads_clip_geom_gist"
  ON "clip_roads"
  USING gist
  (clip_geom);



CREATE TABLE buffer1km_join AS

SELECT
  z.name, z.the_geom,
  sum(ST_Length(b.clip_geom)) AS sum_length_m

FROM
  public."clip_roads" b,
  public."buffer1KM" z

WHERE
  ST_Contains(z.the_geom, b.the_geom)

GROUP BY z.name, z.the_geom;

원래 도로 테이블에 대해 GiST 색인을 작성했으며 두 번째 테이블 작성을 수행하기 전에 색인을 작성하십시오.

PGAdmin III의 쿼리 계획은 다음과 같이 보이지만 해석에 많은 기술이 없습니다.

"Nested Loop  (cost=0.00..29169.98 rows=35129 width=49364)"
"  Output: st_intersection(b.the_geom, z.the_geom), b.gid, b.geo_id, b.address_l, b.address_r, b.lf_name, b.lfn_id, b.lfn_name, b.lfn_type_c, b.lfn_type_d, b.lfn_dir_co, b.lfn_dir_de, b.lfn_desc, b.oe_flag_l, b.oe_flag_r, b.fcode_desc, b.fcode, b.fnode, b.tnode, b.metrd_num, b.lo_num_l, b.lo_n_suf_l, b.hi_num_l, b.hi_n_suf_l, b.lo_num_r, b.lo_n_suf_r, b.hi_num_r, b.hi_n_suf_r, b.juris_code, b.dir_code, b.dir_code_d, b.cp_type, b.length, b.the_geom"
"  Join Filter: _st_intersects(b.the_geom, z.the_geom)"
"  ->  Seq Scan on public."roads" b  (cost=0.00..306.72 rows=5472 width=918)"
"        Output: b.gid, b.geo_id, b.address_l, b.address_r, b.lf_name, b.lfn_id, b.lfn_name, b.lfn_type_c, b.lfn_type_d, b.lfn_dir_co, b.lfn_dir_de, b.lfn_desc, b.oe_flag_l, b.oe_flag_r, b.fcode_desc, b.fcode, b.fnode, b.tnode, b.metrd_num, b.lo_num_l, b.lo_n_suf_l, b.hi_num_l, b.hi_n_suf_l, b.lo_num_r, b.lo_n_suf_r, b.hi_num_r, b.hi_n_suf_r, b.juris_code, b.dir_code, b.dir_code_d, b.cp_type, b.length, b.the_geom"
"  ->  Index Scan using "buffer1KM_index_the_geom" on public."buffer1KM" z  (cost=0.00..3.41 rows=1 width=48446)"
"        Output: z.gid, z.objectid, z.facilityid, z.name, z.frombreak, z.tobreak, z.postal_cod, z.pc_area, z.ct_id, z.da_id, z.taz_id, z.edge_poly, z.cchs_0708, z.tts_06, z.the_geom"
"        Index Cond: (b.the_geom && z.the_geom)"

이 작업은 며칠 동안 실행될 예정입니까? 현재 PostGIS for Windows에서 이것을 실행하고 있지만 이론 상으로는 Amazon EC2에 배치하여 문제에 더 많은 하드웨어를 던질 수 있습니다. 그러나 쿼리가 한 번에 하나의 코어 만 사용한다는 것을 알았습니다 (더 많이 사용할 수있는 방법이 있습니까?).


Postgis는 무엇입니까? OS 및 프로세서가 중요한 요소 일 수 있습니다.
Mapperz

안녕하세요 Mapperz : OS는 Windows 7, CPU는 Core 2 Duo, 메모리는 4GB (Windows, 32 비트 PGSQL / PostGIS 실행)
Peter

답변:


6

베드로,

어떤 버전의 PostGIS, GEOS 및 PostgreSQL을 사용하고 있습니까?
~하다

postgis_full_version (), version ()을 선택하십시오;

1.4와 1.5에서 GEOS 3.2+ 사이에 이런 종류의 기능이 많이 향상되었습니다.

또한 다각형에 몇 개의 정점이 있습니까?

Max (ST_NPoints (the_geom))를 선택하십시오.

최악의 시나리오를 이해합니다. 이와 같은 느린 속도는 종종 너무 결이 거친 형상에 의해 발생합니다. 이 경우 먼저 단순화하고 싶을 수도 있습니다.

또한 postgresql.conf 파일을 최적화 했습니까?


안녕하세요 LR1234567 : "POSTGIS ="1.5.2 "GEOS ="3.2.2-CAPI-1.6.2 "PROJ ="Rel. 4.6.1, 2008 년 8 월 21 일 "LIBXML ="2.7.6 "USE_STATS"; "PostgreSQL 9.0.3, Visual C ++ 빌드 1500, 32 비트로 컴파일 됨"(다른 쿼리 실행)
Peter

최대 쿼리가 예상보다 빠르게 실행되었습니다.
피터

1
2,030은 실제로 나쁘지 않습니다. 교차하는 다각형이 많을 수 있습니다. 일반적으로 교집합은 가장 느린 부분입니다. 실제로 실제로 교차하는 레코드 수를 세어보십시오. 거대 할 수 있습니다.
LR1234567

SELECT count (*) FROM public. "roads"b, public. "buffer1KM"z WHERE ST_Intersects (b.the_geom, z.the_geom);
LR1234567

1
910,978은 거대합니까? 이것은 새로운 기술로 시작하는 것에 대한 좋은 점입니다. 저는 표준적인 기대가 없습니다 :-)
Peter

1

좋은 조언처럼 들립니다. 단일 연결을 실행하고 있기 때문에 fork () 페널티와 같은 일부 Windows 문제는 여기서 문제가되어서는 안됩니다. 또한 VACUUM ANALYZE를 실행했습니다. 나는 아직 성능 최적화를 파헤 치지 않았다.
피터

1
shared_buffers와 work_mem은 일반적으로 가장 큰 차이를 만듭니다. shared_buffers의 경우 리눅스보다 Windows에서 얼마나 많은 양을 제한 할 수 있습니다
LR1234567

shared_buffers는 이미 켜져 있지만 work_mem은 꺼져 있습니다. 지금 1GB의 작업을 추가했습니다.
피터

1

뻔뻔한 플러그 :) 우리 책의 8 장과 9 장을 읽는 데 도움이 될 수 있습니다. 프레스를 뜨겁게하십시오. 우리는이 장에서 이런 종류의 질문을 많이 다룹니다.

http://www.postgis.us/chapter_08

http://www.postgis.us/chapter_09


연결이 끊어졌습니다. PostGIS 작동 또는 PostGIS 요리 책을 의미합니까?
HeikkiVesanto

1
아 맞아. 그것들은 PostGIS in Action의 초판에 대한 링크였습니다. 당시에는 유효했습니다. 2 판을 도입했을 때 링크 구조를 변경해야했습니다. 언급 된 이전 링크는 다음과 같습니다. postgis.us/chapters_edition_1
LR1234567

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.