PostGIS ST_Union Performa

Saya mencoba menjalankan operasi 'bubar' di PostGIS menggunakan perintah ST_Union.

Lapisan input diakui cukup besar dan kompleks. Maksudnya 'besar' adalah 57.771 fitur, dengan jumlah simpul mulai dari 4 hingga 758.018 per fitur, rata-rata sekitar 86 simpul per fitur. Hanya sekitar 10 fitur yang memiliki> 10.000 simpul. Maksudnya 'kompleks' yang saya maksud adalah poligon memiliki banyak lubang, tumpang tindih yang berantakan, pulau, dll. Dan bahwa poligon besar cenderung memiliki kotak pembatas yang menutupi banyak poligon yang lebih kecil, mungkin indeks render kurang berguna.

Masalahnya adalah bahwa permintaan sangat lambat sampai tidak dapat digunakan lagi. Saya membaca posting Paul 2009 di sini yang membuat saya percaya bahwa permintaan saya masih harus cukup cepat. Saya menggunakan perintah berikut; apakah saya melakukan sesuatu yang salah atau tidak efisien?

SELECT  ST_Union(f.geom) as geom, column1,column2,column3
FROM "inputlayer" As f 
GROUP BY column1,column2,column3

Sunting: Saya menggunakan:

POSTGIS="2.1.4 r12966" GEOS="3.3.3-CAPI-1.7.4" PROJ="Rel. 4.7.1, 23 September 2009" GDAL="GDAL 2.0.0dev, released 2014/04/16" LIBXML="2.7.8" LIBJSON="UNKNOWN" TOPOLOGY RASTER PostgreSQL 9.3.5 on x86_64-unknown-linux-gnu, compiled by gcc (Ubuntu/Linaro 4.6.3-1ubuntu5) 4.6.3, 64-bit

Mesin yang saya jalankan di server db adalah mesin virtual tanpa banyak daya. Saya akan mencoba SET work_mem = 50000 ide dan melihat bagaimana hasilnya!

— Darren Cope
sumber

Untuk lebih jelasnya, Anda ingin penyatuan geometri untuk setiap kombinasi dari kolom1, kolom2 dan kolom3? Bisakah Anda mendefinisikan besar, kompleks dan lambat dan apa yang menjelaskan pertunjukan?

— John Powell

John; ya, saya ingin penyatuan untuk setiap kombinasi kolom1, 2 dan 3. Saya tidak yakin bagaimana mengukur 'besar' - tetapi ini adalah sejumlah poligon yang sangat kompleks (banyak simpul) dengan tumpang tindih dan pulau-pulau yang berantakan, dll. Saya 'Saya harus melakukan riset untuk' menjelaskan 'sebelum saya dapat menjawab pertanyaan terakhir Anda!

— Darren Cope

Jelaskan mungkin tidak terlalu membantu dalam kasus ini, karena sebagian besar mengukur waktu mencari disk untuk benar-benar membaca baris, berdasarkan tabel statistik, indeks, dll. Ini tidak memperhitungkan waktu menjalankan fungsi seperti ST_Union, yang tergantung pada kompleksitas poligon, jumlah tumpang tindih, dll.

— John Powell

Harap edit pertanyaan untuk menambahkan detail.

— Vince

Tergantung juga pada versi GEOS Anda. Algoritma agregasi yang lebih baik diperkenalkan pada versi 3.1.0.

— Scro

Jawaban:

Operasi semacam ini menggunakan banyak memori kerja seperti yang saya ingat, jadi Anda ingin memastikan Anda tidak pada pengaturan default untuk ini yang sangat rendah;

Coba sesuatu seperti

SET work_mem=50000;
Then run your query

Anda mungkin ingin bermain-main dengan pengaturan workmem itu

Anda juga ingin membuangnya ke dalam tabel - bukan output ke layar. Saya berasumsi Anda sudah tahu itu

Hal-hal lain yang ingin Anda verifikasi - yang saya berikan komentar tetapi akan ulangi di sini:

Ada dua hal yang meningkatkan kecepatan penyatuan - hal kaskade yang Anda tunjukkan, dan untuk poligon menghitung akumulasi array lebih cepat (yang saya pikir datang dalam PostGIS 1.5 (mungkin 1.4 tidak dapat mengingat), PostgreSQL 8.4 (mungkin 9.0 dapat ingat)). Bahkan GEOS yang lebih baru tidak akan ada gunanya jika Anda menjalankan <PostGIS 1.4

Jadi memeriksa versi postgis dan versi postgresql adalah penting

SELECT postgis_full_version() || ' ' || version();

— LR1234567
sumber

Ada juga ST_MemUnion. Penggunaan memori kurang, lebih prosesor: postgis.net/docs/ST_MemUnion.html

— Scro

Fungsi itu sudah cukup tua. Saya pikir implemntation ST_Union baru sebenarnya menghemat memori lebih baik dari fungsi itu.

— LR1234567

Bahkan sebelum Anda menjalankan ST_Union

ANALISIS basis data Anda untuk memperbarui statistik kueri.

VACUUM database Anda untuk membersihkan jika Anda belum menjalankan Autovacuum. Periksa pengaturan utama Anda untuk memastikan bahwa mereka diatur ke nilai yang masuk akal ..

shared_buffers should be 10% to 25% of available RAM
effective_cache_size should be 75% of available RAM

Uji perubahan work_mem : tingkatkan menjadi 8MB, 32MB, 256MB, 1GB. Apakah itu membuat perbedaan?

* 32MB adalah default

sumber: https://wiki.postgresql.org/wiki/Tuning_Your_PostgreSQL_Server

— Mapperz
sumber

Terima kasih. Saya baru saja mencoba ANALYZE, VACUUM dan meningkatkan shared_buffers dan efektif_cache_size, dan memiliki masalah yang sama. Saya akan terus mengutak-atik jika waktu memungkinkan.

— Darren Cope

@ DarrenCope kemajuan? Saya menghadapi masalah yang sama.

— Michal Zimmermann

@zimmi; sayangnya tidak :( Saya masih di tempat saya sebelumnya! Apakah Anda melakukan hal yang sama persis? Mungkin berbagi contoh dan lihat apakah ada kesamaan

— Darren Cope

@DarrenCope ST_Buffer (St_Collect (wkb_geometry), 0) tampaknya jauh lebih cepat dan sesuai dengan kebutuhan saya. Mungkin membantu Anda juga.

— Michal Zimmermann