การสอบถาม ST_Intersection ช้า


11

ฉันพยายามแยกระหว่างสองชั้น:

  1. Polyline layer แสดงถนนบางเส้น (ประมาณ 5500 แถว)
  2. ชั้นรูปหลายเหลี่ยมที่แสดงบัฟเฟอร์รูปร่างผิดปกติรอบ ๆ จุดที่น่าสนใจต่างๆ (ประมาณ 47,000 แถว)

ท้ายที่สุดสิ่งที่ฉันพยายามทำคือตัดคลิป polylines ไปยังบัฟเฟอร์ (บางครั้งซ้อนทับกัน) เหล่านี้แล้วสรุปความยาวรวมของถนนที่อยู่ในบัฟเฟอร์แต่ละอัน

ปัญหาคือสิ่งที่กำลังทำงานช้า ฉันไม่แน่ใจว่าจะใช้เวลานานเท่าใด แต่ฉันเพิ่งยกเลิกการสืบค้นหลังจาก> 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 สำหรับ Windows แต่ในทางทฤษฎีแล้วฉันสามารถเพิ่มฮาร์ดแวร์ให้กับปัญหาได้โดยวางลงบน Amazon EC2 อย่างไรก็ตามฉันเห็นว่าแบบสอบถามใช้เพียงหนึ่งคอร์ในแต่ละครั้ง (มีวิธีที่จะทำให้ใช้มากกว่าหรือไม่)


Postgis กำลังทำงานอะไรอยู่ ระบบปฏิบัติการและตัวประมวลผลอาจเป็นปัจจัย
Mapperz

สวัสดี Mapperz: ระบบปฏิบัติการคือ Windows 7, CPU เป็น Core 2 Duo, หน่วยความจำ 4GB (เป็น Windows, ใช้ PGSQL / PostGIS 32 บิต)
Peter

คำตอบ:


6

ปีเตอร์

คุณใช้ PostGIS, GEOS และ PostgreSQL เวอร์ชันใดอยู่
ทำ

SELECT postgis_full_version (), version ();

มีการปรับปรุงมากมายระหว่าง 1.4 ถึง 1.5 และ GEOS 3.2+ สำหรับสิ่งนี้

รูปหลายเหลี่ยมของคุณมีจุดยอดเท่าไร?

ทำ

เลือกสูงสุด (ST_NPoints (the_geom)) เป็นค่าสูงสุดจากบางครั้ง;

เพื่อให้เข้าใจถึงสถานการณ์กรณีที่เลวร้ายที่สุดของคุณ ความเร็วช้าเช่นนี้มักเกิดจากรูปทรงที่มีขนาดเล็กเกินไป ในกรณีนี้คุณอาจต้องทำให้ง่ายขึ้นก่อน

คุณเพิ่มประสิทธิภาพให้กับไฟล์ postgresql.conf ด้วยหรือไม่


สวัสดี LR1234567: "POSTGIS =" 1.5.2 "GEOS =" 3.2.2-CAPI-1.6.2 "PROJ =" Rel 4.6.1, 21 สิงหาคม 2551 "LIBXML =" 2.7.6 "USE_STATS"; "PostgreSQL 9.0.3 รวบรวมโดย Visual C ++ build 1500, 32 บิต" (เรียกใช้คิวรีอื่นตอนนี้)
Peter

ข้อความค้นหาสูงสุดวิ่งเร็วกว่าที่ฉันคาดไว้: maxp = 2030 ฉันสงสัยว่ามันค่อนข้างละเอียดใช่ไหม
ปีเตอร์

1
2,030 ไม่เลวจริง ๆ อาจเป็นเพราะคุณมีรูปหลายเหลี่ยมหลายจุดตัดกัน โดยทั่วไปทางแยกเป็นส่วนที่ช้าที่สุด .. ลองนับดูว่ามีเร็กคอร์ดจำนวนมากตัดกันจริงหรือไม่
LR1234567

เลือกจำนวน (*) จากสาธารณะ "ถนน" b สาธารณะ "บัฟเฟอร์1KM" z WHERE ST_Intersects (b.the_geom, z.the_geom);
LR1234567

1
มีขนาด 910,978 อันหรือไม่ นี่เป็นสิ่งที่ดีเกี่ยวกับการเริ่มต้นกับเทคโนโลยีใหม่ - ฉันไม่มีความคาดหวังเชิงบรรทัดฐาน :-)
ปีเตอร์

1

คำตอบแลกเปลี่ยนสแต็คที่มีประโยชน์: /programming/1162206/why-is-postgresql-so-slow-on-windows

การปรับ postgres: http://wiki.postgresql.org/wiki/Performance_Optimization

จากประสบการณ์แนะนำVACUUM ANALYZE


ขอบคุณที่ฟังดูเหมือนคำแนะนำที่ดี ปัญหาของ Windows บางอย่างเช่นการลงโทษ fork () ไม่ควรเป็นปัญหาที่นี่เพราะฉันใช้การเชื่อมต่อเดียวใช่ไหม นอกจากนี้ยังมีการเรียกใช้ VACUUM ANALYZE ฉันยังไม่ได้ขุดหาการปรับประสิทธิภาพให้เหมาะสม
ปีเตอร์

1
shared_buffers และ work_mem สร้างความแตกต่างได้มากที่สุด สำหรับ shared_buffers คุณมีข้อ จำกัด อีกเล็กน้อยว่าคุณสามารถทำสิ่งนั้นบน windows ได้มากกว่าลินุกซ์
LR1234567

shared_buffers เปิดใช้งานแล้ว แต่ work_mem ปิดอยู่ ฉันเพิ่มบันทึกการทำงาน 1 GB แล้ว
ปีเตอร์

1

ปลั๊กไร้ยางอาย :) อาจช่วยอ่านบทที่ 8 และบทที่ 9 ของหนังสือของเรา เพิ่งร้อนจากการกด เราครอบคลุมคำถามประเภทนี้มากมายในบทเหล่านั้น

http://www.postgis.us/chapter_08

http://www.postgis.us/chapter_09


ลิงก์ใช้งานไม่ได้นี่หมายถึง PostGIS in Action หรือ PostGIS Cookbook หรือไม่
HeikkiVesanto

1
อาคุณพูดถูก สิ่งเหล่านี้เป็นลิงค์ไปยังรุ่นแรกของ PostGIS in Action - ซึ่งใช้ได้ในตอนนั้น เมื่อเราแนะนำรุ่นที่ 2 เราต้องเปลี่ยนโครงสร้างลิงค์ ลิงก์เก่า ๆ ที่อ้างถึงตอนนี้อยู่ที่นี่: postgis.us/chapters_edition_1
LR1234567

0

ดูเคล็ดลับสองข้อในการเพิ่มประสิทธิภาพการสืบค้นเชิงพื้นที่ พวกเขาทำงานได้ดีสำหรับฉัน http://kb.zillionics.com/optimize-spatial-query/


2
คำตอบนี้จะดีขึ้นโดยมีรายละเอียดเพิ่มเติมเช่นวิธีการใช้ในสถานการณ์เฉพาะนี้
BradHards
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.