ST_Intersection truy vấn chậm


11

Tôi đang cố gắng thực hiện một giao điểm giữa hai lớp:

  1. Lớp polyline đại diện cho một số đường (~ 5500 hàng)
  2. Lớp đa giác biểu thị bộ đệm có hình dạng không đều xung quanh các điểm quan tâm khác nhau (~ 47.000 hàng)

Cuối cùng, những gì tôi đang cố gắng làm là cắt các polylines cho nhiều bộ đệm (đôi khi chồng chéo) này, và sau đó tổng hợp tổng chiều dài đường có trong mỗi bộ đệm.

Vấn đề là mọi thứ đang chạy SLOW. Tôi không chắc sẽ mất bao lâu, nhưng tôi đã hủy bỏ truy vấn của mình sau> 34 giờ. Tôi hy vọng rằng ai đó có thể chỉ ra nơi tôi đã mắc một số lỗi với truy vấn SQL của mình hoặc có thể chỉ cho tôi cách làm việc này tốt hơn.

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;

Tôi có một chỉ mục GiST được tạo cho bảng đường ban đầu và (để an toàn?) Tạo một chỉ mục trước khi thực hiện tạo bảng thứ hai.

Kế hoạch truy vấn từ PGAdmin III trông như thế này, mặc dù tôi e rằng tôi không có nhiều kỹ năng trong việc diễn giải nó:

"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)"

Là hoạt động này chỉ cam chịu để chạy trong vài ngày? Tôi hiện đang chạy cái này trên PostGIS cho Windows, nhưng về lý thuyết tôi có thể giải quyết nhiều vấn đề về phần cứng hơn bằng cách đưa nó lên Amazon EC2. Tuy nhiên, tôi thấy rằng truy vấn chỉ sử dụng một lõi tại một thời điểm (có cách nào để làm cho nó sử dụng nhiều hơn không?).


Postgis đang chạy trên cái gì? Hệ điều hành và Bộ xử lý có thể là một yếu tố.
Mapperz

Xin chào Mapperz: HĐH là Windows 7, CPU là Core 2 Duo, Bộ nhớ là 4GB (là Windows, chạy PG-32 / PostGIS 32-bit)
Peter

Câu trả lời:


6

Peter

Phiên bản nào của PostGIS, GEOS và PostgreSQL bạn đang sử dụng?
làm một

CHỌN postgis_full_version (), phiên bản ();

Rất nhiều cải tiến đã được thực hiện trong khoảng từ 1,4 đến 1,5 và GEOS 3.2+ cho loại điều này.

Ngoài ra có bao nhiêu đỉnh để đa giác của bạn có?

Làm một

CHỌN Max (ST_NPoints (the_geom)) Là tối đa TỪ đôi khi;

Để có được một cảm giác về trường hợp xấu nhất của bạn. Tốc độ chậm như thế này thường được gây ra bởi hình học quá cuối cùng. Trong trường hợp bạn có thể muốn đơn giản hóa đầu tiên.

Ngoài ra, bạn đã thực hiện tối ưu hóa cho tập tin postgresql.conf của bạn?


Xin chào LR1234567: "POSTGIS =" 1.5.2 "GEOS =" 3.2.2-CAPI-1.6.2 "PROJ =" Rel. 4.6.1, ngày 21 tháng 8 năm 2008 "LIBXML =" 2.7.6 "USE_STATS"; "PostgreQuery 9.0.3, được biên soạn bởi Visual C ++ build 1500, 32-bit" (chạy truy vấn khác ngay bây giờ)
Peter

Truy vấn Max chạy nhanh hơn tôi mong đợi: maxp = 2030 Tôi nghi ngờ đó là hạt khá tốt?
Peter

1
2.030 thực sự không tệ. Nó có thể là bạn chỉ có rất nhiều đa giác giao nhau. Nói chung, giao lộ là phần chậm nhất .. Hãy thử đếm xem có bao nhiêu bản ghi thực sự giao nhau - nó có thể rất lớn.
LR1234567

CHỌN đếm (*) TỪ công khai. "Đường" b, công khai. "Đệm1KM" z WHERE ST_Intersects (b.the_geom, z.the_geom);
LR1234567

1
Là 910.978 rất lớn? Đây là điều tuyệt vời khi bắt đầu với một công nghệ mới - Tôi không có kỳ vọng chuẩn mực :-)
Peter

1

câu trả lời trao đổi ngăn xếp hữu ích: /programming/1162206/why-is-postgresql-so-slow-on-windows

Điều chỉnh postgres: http://wiki.postgresql.org/wiki/Performance_Optimization

từ kinh nghiệm khuyên dùng VACUUM ANALYZE


Cảm ơn bạn, đó có vẻ là lời khuyên tốt. Một số vấn đề của Windows như hình phạt fork () không phải là vấn đề ở đây vì tôi đang chạy một kết nối, phải không? Ngoài ra, đã chạy VACUUM ANALYZE. Tôi chưa đi sâu vào bất kỳ tối ưu hóa hiệu suất nào mặc dù.
Peter

1
shared_buffers và work_mem thường tạo ra sự khác biệt nhất. Đối với shared_buffers, bạn bị giới hạn hơn một chút về số tiền bạn có thể tăng trên windows so với trên linux
LR1234567

shared_buffers đã được bật, nhưng work_mem đã tắt. Tôi đã thêm 1 GB mem công việc bây giờ.
Peter

1

Ổ cắm không biết xấu hổ :) Có thể giúp đọc chương 8 và chương 9 của cuốn sách của chúng tôi. Chỉ cần nóng tắt máy ép. Chúng tôi bao gồm rất nhiều loại câu hỏi trong các chương đó.

http://www.postgis.us/ch CHƯƠNG_08

http://www.postgis.us/ch CHƯƠNG_09


Liên kết bị hỏng, đây có phải là đề cập đến PostGIS in Action hay PostGIS Cookbook không?
HeikkiVesanto

1
à bạn nói đúng Đó là những liên kết đến phiên bản đầu tiên của PostGIS in Action - lúc đó đã hợp lệ. Khi chúng tôi giới thiệu phiên bản 2, chúng tôi phải thay đổi cấu trúc liên kết. Các liên kết cũ được đề cập hiện có tại đây: postgis.us/chaptfteededition_1
LR1234567

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.