ST_Intersection, permintaan lambat


11

Saya mencoba melakukan persimpangan antara dua lapisan:

  1. Lapisan polyline mewakili beberapa jalan (~ 5500 baris)
  2. Lapisan poligon mewakili buffer berbentuk tidak teratur di sekitar berbagai tempat menarik (~ 47.000 baris)

Pada akhirnya, apa yang saya coba lakukan adalah untuk memotong polylines ke banyak (kadang tumpang tindih) buffer ini, dan kemudian meringkas total panjang jalan yang terkandung dalam setiap buffer.

Masalahnya adalah bahwa semuanya berjalan lambat. Saya tidak yakin berapa lama ini harus dilakukan, tetapi saya baru saja membatalkan permintaan saya setelah> 34 jam. Saya berharap bahwa seseorang dapat menunjukkan di mana saya telah membuat kesalahan dengan permintaan SQL saya, atau dapat mengarahkan saya ke cara yang lebih baik untuk melakukan ini.

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;

Saya memiliki indeks GiST yang dibuat untuk tabel jalan asli, dan (hanya untuk aman?) Membuat indeks sebelum melakukan pembuatan tabel kedua.

Rencana kueri dari PGAdmin III terlihat seperti ini, meskipun saya khawatir saya tidak memiliki banyak keterampilan dalam menafsirkannya:

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

Apakah operasi ini hanya akan berjalan selama beberapa hari? Saya saat ini menjalankan ini pada PostGIS untuk Windows, tetapi secara teori saya dapat melemparkan lebih banyak perangkat keras pada masalah dengan meletakkannya di Amazon EC2. Namun, saya melihat bahwa kueri hanya menggunakan satu inti pada satu waktu (apakah ada cara untuk membuatnya menggunakan lebih banyak?).


Apa yang Postgis jalankan? OS dan Prosesor mungkin menjadi faktor.
Mapperz

Hai Mapperz: OS adalah Windows 7, CPU adalah Core 2 Duo, Memori 4GB (menjadi Windows, menjalankan 32-bit PGSQL / PostGIS)
Peter

Jawaban:


6

Peter,

Versi PostGIS, GEOS, dan PostgreSQL apa yang Anda gunakan?
lakukan a

SELECT postgis_full_version (), version ();

Banyak perangkat tambahan telah dibuat antara 1,4 dan 1,5 dan GEOS 3,2+ untuk hal semacam ini.

Juga berapa banyak simpul yang dimiliki poligon Anda?

Lakukan a

SELECT Max (ST_NPoints (the_geom)) Sebagai maks FROM kadang-kadang;

Untuk memahami skenario terburuk Anda. Kecepatan lambat seperti ini sering disebabkan oleh geometri yang akhirnya berbutir. Dalam hal ini Anda mungkin ingin menyederhanakan terlebih dahulu.

Anda juga sudah optimalkan file postgresql.conf Anda?


Hai LR1234567: "POSTGIS =" 1.5.2 "GEOS =" 3.2.2-CAPI-1.6.2 "PROJ =" Rel. 4.6.1, 21 Agustus 2008 "LIBXML =" 2.7.6 "USE_STATS"; "PostgreSQL 9.0.3, dikompilasi oleh Visual C ++ build 1500, 32-bit" (menjalankan kueri lain sekarang)
Peter

Kueri Max berjalan lebih cepat dari yang saya harapkan: maxp = 2030 Saya menduga itu cukup baik?
Peter

1
2.030 sebenarnya tidak buruk. Bisa jadi Anda hanya memiliki banyak poligon yang berpotongan. Umumnya persimpangan adalah bagian yang paling lambat .. Coba lakukan penghitungan pada berapa banyak catatan yang benar-benar berpotongan - itu bisa sangat besar.
LR1234567

SELECT menghitung (*) DARI publik. "Jalan" b, publik. "Buffer1KM" z WHERE ST_Intersects (b.the_geom, z.the_geom);
LR1234567

1
Apakah 910.978 besar? Ini adalah hal yang menyenangkan tentang memulai teknologi baru - Saya tidak punya harapan normatif :-)
Peter

1

jawaban pertukaran tumpukan yang bermanfaat: /programming/1162206/why-is-postgresql-so-slow-on-windows

Tuning postgres: http://wiki.postgresql.org/wiki/Performance_Optimization

dari pengalaman merekomendasikan VACUUM ANALYZE


Terima kasih, itu kedengarannya seperti saran yang bagus. Beberapa masalah Windows seperti fork () penalti seharusnya tidak menjadi masalah di sini karena saya menjalankan satu koneksi, bukan? Juga, jalankan VACUUM ANALYZE. Saya belum menggali optimasi kinerja apa pun.
Peter

1
shared_buffers dan work_mem umumnya membuat perbedaan paling besar. Untuk shared_buffers Anda sedikit lebih terbatas seberapa banyak Anda dapat melakukan itu di windows daripada di linux
LR1234567

shared_buffers sudah menyala, tetapi work_mem tidak aktif. Saya telah menambahkan 1 GB memo kerja sekarang.
Peter

1

Steker tak tahu malu :) Tolong bantu untuk membaca bab 8 dan bab 9 buku kami. Hanya panas dari mesin cetak. Kami membahas banyak pertanyaan semacam ini di bab-bab itu.

http://www.postgis.us/chapter_08

http://www.postgis.us/chapter_09


Tautan terputus, apakah ini mengacu pada PostGIS Beraksi atau Buku Mas PostGIS?
HeikkiVesanto

1
ah kamu benar Itu adalah tautan ke edisi pertama PostGIS in Action - yang berlaku saat itu. Ketika kami memperkenalkan edisi ke-2, kami harus mengubah struktur tautan. Tautan lama yang dimaksud sekarang ada di sini: postgis.us/chapters_edition_1
LR1234567

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.