PostGIS ST_Unionパフォーマンス

ST_Unionコマンドを使用してPostGISで「ディゾルブ」操作を実行しようとしています。

入力層は確かに非常に大きく複雑です。「大きい」とは、57,771のフィーチャを意味し、頂点の数はフィーチャあたり4〜758,018の範囲であり、平均してフィーチャあたり約86の頂点です。頂点の数が10,000を超えるのは約10のフィーチャだけです。「複雑な」とは、ポリゴンに多数の穴、乱雑なオーバーラップ、アイランドなどがあり、大きなポリゴンには、小さなポリゴンの多くをカバーする境界ボックスがあり、おそらくインデックスの有用性が低いことを意味します。

問題は、クエリが非常に遅くなり、使用できなくなることです。私はここでポールの2009年の投稿を読んだので、私のクエリはまだかなり高速であるはずだと思いました。次のコマンドを使用しています。私は露骨に間違っている、または非効率的なことをしていますか？

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

編集：私は使用しています：

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

私がdbサーバーを実行しているマシンは、パワーのない仮想マシンです。SET work_mem = 50000のアイデアを試してみて、どうなるか見てみましょう！

この種の操作は、私が覚えているように大量の作業メモリを使用するため、かなり低いデフォルト設定になっていないことを確認する必要があります。

のようなものを試してください

SET work_mem=50000;
Then run your query

あなたはそのworkmem設定で遊んでみたいかもしれません

画面に出力するのではなく、それをテーブルにダンプすることもできます。私はあなたがすでにそれを知っていると思います

あなたが確認したい他のこと-私はコメントに入れましたが、ここで繰り返します：

ユニオンの速度を改善した2つの点があります-あなたが指摘したカスケードの点と、ポリゴンカウントの場合、より高速な配列アキュムレーション（PostGIS 1.5（1.4は思い出せないかもしれません）にあると思います）、PostgreSQL 8.4（マイグレーション9.0は可能）思い出せない））。また、<PostGIS 1.4を実行している場合は、新しいGEOSでもうまく機能しません。

したがって、postgisバージョンとpostgresqlバージョンの両方をチェックすることが重要です

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

ST_Unionを実行する前でも

データベースを分析してクエリ統計を更新します。

Autovacuumをまだ実行していない場合は、データベースをVACUUMしてパージします。メイン設定をチェックして、適切な値に設定されていることを確認してください。

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

work_memを変更してテストします。8MB、32MB、256MB、1GBに増やします。違いはありますか？

* 32MBがデフォルトです

ソース：https : //wiki.postgresql.org/wiki/Tuning_Your_PostgreSQL_Server