ST_Intersection yavaş sorgu


11

İki katman arasında bir kavşak gerçekleştirmeye çalışıyorum:

  1. Bazı yolları temsil eden çoklu katman (~ 5500 satır)
  2. Çeşitli ilgi noktalarında (~ 47.000 satır) düzensiz şekilli tamponları temsil eden çokgen katman

Nihayetinde, yapmaya çalıştığım şey, çok sayıda (bazen çakışan) tamponlara çoklu çizgileri kırpmak ve daha sonra her bir tampon içindeki toplam yol uzunluğunu özetlemektir.

Sorun şu ki, şeyler YAVAŞ çalışıyor. Bunun ne kadar sürmesi gerektiğinden emin değilim, ancak sorgumu> 34 saat sonra iptal ettim. Birisi ya SQL sorgu ile bazı hata yaptım nerede işaret edebilir, ya da bana bunu yapmak için daha iyi bir yol işaret umuyoruz.

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;

Orijinal yollar tablo için oluşturulan bir GiST dizini var ve (sadece güvenli olmak için?) İkinci tablo oluşturma yapmadan önce bir dizin oluşturmak.

Korkarım ki PGAdmin III'ten gelen sorgu planı şuna benziyor: Bunu yorumlama konusunda çok fazla yeteneğim yok:

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

Bu işlem birkaç gün sürecek mi? Şu anda Windows için PostGIS'de çalıştırıyorum, ancak teorik olarak Amazon EC2'ye koyarak daha fazla donanım atabilirim. Ancak, sorgu tek seferde yalnızca bir çekirdek kullandığını görüyorum (daha fazla kullanmak için bir yolu var mı?).


Postgis ne üzerinde çalışıyor? İşletim Sistemi ve İşlemci bir faktör olabilir.
Mapperz

Merhaba Mapperz: İşletim Sistemi Windows 7, CPU Core 2 Duo, Bellek 4GB (Windows olmak, 32 bit PGSQL / PostGIS çalıştıran)
Peter

Yanıtlar:


6

Peter,

Hangi PostGIS, GEOS ve PostgreSQL sürümünü kullanıyorsunuz?
yap

Postgis_full_version (), sürüm () SEÇ;

Bu tür şeyler için 1.4 ile 1.5 ve GEOS 3.2+ arasında birçok geliştirme yapıldı.

Ayrıca çokgenlerinizde kaç köşe noktası var?

Yapın

Maks. SELECT (ST_NPoints (the_geom)) Bazıları için maxp FROM olarak;

En kötü senaryoyu anlamak için. Bunun gibi düşük hız, genellikle çok nihayetinde tanelenen geometrilerden kaynaklanır. Bu durumda önce basitleştirmek isteyebilirsiniz.

Ayrıca postgresql.conf dosyanızda optimizasyon yaptınız mı?


Merhaba LR1234567: "POSTGIS =" 1.5.2 "GEOS =" 3.2.2-CAPI-1.6.2 "PROJ =" Rel. 4.6.1, 21 Ağustos 2008 "LIBXML =" 2.7.6 "USE_STATS"; "PostgreSQL 9.0.3, derlenmiş Visual C ++ derleme 1500, 32-bit" (diğer sorguyu şimdi çalıştırıyor)
Peter

Max sorgu beklediğimden daha hızlı koştu: maxp = 2030 Oldukça ince taneli şüpheli?
Peter

1
2.030 aslında fena değil. Kesişen çok fazla çokgeniniz olabilir. Genellikle kavşak en yavaş olan kısımdır .. Gerçekte kaç kaydın kesiştiği bir sayım yapmayı deneyin - çok büyük olabilir.
LR1234567

SELECT sayısı (*) herkesten. "Yollar" b, genel. "Buffer1KM" z WHERE ST_Intersects (b.the_geom, z.the_geom);
LR1234567

1
910.978 çok mu büyük? Bu yeni bir teknolojiye başlamakla ilgili güzel bir şey - Normatif beklentilerim yok :-)
Peter

1

Teşekkürler, kulağa iyi bir tavsiye gibi geliyor. Çatal () cezası gibi bazı Windows sorunları burada bir sorun olmamalı çünkü tek bir bağlantı çalıştırıyorum, değil mi? Ayrıca, VAKUM ANALİZİ çalıştırın. Yine de herhangi bir performans optimizasyonuna girmedim.
Peter

1
shared_buffers ve work_mem genellikle en büyük farkı yaratır. Shared_buffers için windows üzerinde ne kadar yukarı linux üzerinde olduğundan daha sınırlı
LR1234567

shared_buffers zaten açıktı, ama work_mem kapalıydı. Şimdi 1 GB çalışma belleği ekledim.
Peter

1

Utanmaz fiş :) Kitabımızın 8. ve 9. bölümlerini okumak yardımcı olabilir. Sadece presleri ısıtın. Bu bölümlerde bu tür birçok soruyu ele alıyoruz.

http://www.postgis.us/chapter_08

http://www.postgis.us/chapter_09


Bağlantılar koptu, bu PostGIS in Action ya da PostGIS Cookbook ile mi ilgili?
HeikkiVesanto

1
ah haklısın. Bunlar, PostGIS in Action'ın ilk baskısının bağlantılarıydı - o zamanlar geçerliydi. 2. baskıyı tanıttığımızda bağlantı yapısını değiştirmek zorunda kaldık. Bahsedilen
LR1234567

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.