Performances PostGIS ST_Union

J'essaie d'exécuter une opération de «dissolution» dans PostGIS à l'aide de la commande ST_Union.

La couche d'entrée est certes assez grande et complexe. Par «grand», j'entends 57 771 entités, avec un nombre de sommets allant de 4 à 758 018 par entité, avec une moyenne d'environ 86 sommets par entité. Seulement environ 10 des entités ont> 10 000 sommets. Par `` complexe '', je veux dire que les polygones ont beaucoup de trous, des chevauchements désordonnés, des îles, etc. et que les grands polygones ont tendance à avoir un cadre de délimitation qui couvre la plupart des polygones plus petits, ce qui rend peut-être les index moins utiles.

Le problème est que la requête est extrêmement lente au point d'être inutilisable. J'ai lu ici le billet de 2009 de Paul qui me porte à croire que ma requête devrait toujours être assez rapide. J'utilise la commande suivante; est-ce que je fais quelque chose de manifestement faux ou inefficace?

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

Edit: j'utilise:

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

La machine sur laquelle j'utilise le serveur db est une machine virtuelle sans beaucoup de puissance. Je vais essayer l'idée SET work_mem = 50000 et voir comment ça se passe!

Ce type d'opération utilise beaucoup de mémoire de travail si je me souviens bien, vous devez donc vous assurer que vous n'êtes pas aux paramètres par défaut pour ce qui est assez bas;

Essayez quelque chose comme

SET work_mem=50000;
Then run your query

Vous voudrez peut-être jouer avec ce paramètre de workmem

Vous voudrez également le vider dans une table - pas la sortie à l'écran. Je suppose que vous le savez déjà

Autres choses que vous souhaitez vérifier - que je mets dans les commentaires mais que je répéterai ici:

Il y a deux choses qui ont amélioré la vitesse de l'union - la chose en cascade que vous avez signalée, et pour le nombre de polygones, l'accumulation de tableaux plus rapide (qui, je pense, est venue dans PostGIS 1.5 (peut-être 1,4 ne se souvient pas), PostgreSQL 8.4 (migth be 9.0 can ne me souviens pas)). De plus, même un nouveau GEOS ne fera pas de bien si vous utilisez <PostGIS 1.4

Il est donc important de vérifier la version postgis et la version postgresql

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

Avant même d'exécuter ST_Union

ANALYSER votre base de données pour mettre à jour les statistiques des requêtes.

Videz votre base de données pour la purger si vous n'exécutez pas déjà Autovacuum. Vérifiez vos paramètres principaux pour vous assurer qu'ils sont définis sur des valeurs sensibles.

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

Testez la modification de work_mem : augmentez-la à 8 Mo, 32 Mo, 256 Mo, 1 Go. Est-ce que cela fait une différence?

* 32 Mo par défaut

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