Une requête qui ne s'exécute jamais

[nabil.brarou]

Bonjour chers SGBD users,

J'ai une requête SQL sous PostgreSQL qui ne s'exécute jamais et n'affiche pas d'erreurs.
J'ignore complétement la raison d’être, toutefois la base de données ne contient pas d'erreurs et tout semble bien mis, quoique vu que je manipule des données géographiques, je pense que l'erreur se cache ici ?
Voici ma requête :

Code :

1
2
3
4
5
CREATE TABLE tv_localisation_polygone_zoneshumides AS
SELECT loc_id_localisation, lpo_id_localisation_polygone, 
tv_geom_zones_humides.gez_id_geom_zonage 
FROM t_localisation_polygone,tv_geom_zones_humides
WHERE intersects(tv_geom_zones_humides.gez_geometry, t_localisation_polygone.lpo_geometry) ;

La fonction intersects est une fonction spatiale, i.e traite les données géo comme (points, lignes, polygones) elle cherche l'intersection entre les deux paramètres.

Des propositions pourront me satisfaire, et de m'assurer de l'existence d'une solution.
Merci d'avance.

[ced]

Bonjour,

Par "qui ne s'exécute jamais", vous voulez bien dire que la table en question n'est pas créée ?
Qu'est-ce que ça donne quand vous enlevez la première ligne CREATE TABLE tv_localisation_polygone_zoneshumides AS ?

[nabil.brarou]

Elle ne s’exécute pas non plus, je lance la requête sous pgAdmin 3 et j'attends des heures et des heures.
Quelqu'un peut-il m'aider la dessus ?
J'en serais très reconnaissant.

[ced]

Et au lieu de lancer la requête, que donne l'affichage de son plan d'exécution ?

Code :

EXPLAIN... la requête

[SQLpro]

1) quel est le volume/nombre des lignes des tables ?
2) les colonnes spatiales tv_geom_zones_humides.gez_geometry et t_localisation_polygone.lpo_geometry sont-elles indexées ?

A +

[nabil.brarou]

Je m'excuse pour le retard !!!

Le plan d'exécution est comme suit :

Code :

1
2
3
4
Nested Loop  (cost=0.00..1429840117.96 rows=10509691989 width=12)
  JOIN Filter: intersects(tv_geom_zones_humides.gez_geometry, t_localisation_polygone.lpo_geometry)
  ->  Seq Scan ON tv_geom_zones_humides  (cost=0.00..1773.76 rows=26376 width=2038)
  ->  Seq Scan ON t_localisation_polygone  (cost=0.00..39267.70 rows=1195370 width=13145)

Pour la table tv_geom_zones_humides :
- le nombre de ligne de la colonne gez_geometry : 26376
Pour la table t_localisation_polygone :
- le nombre de ligne de la colonne lpo_geometry :1.19537e+06

Les tables ne sont pas indexées.

[nabil.brarou]

C'est peut etre à cause de la non indexation des colonnes spatiales que ça bug, mais je ne suis pas sur, en tout cas le chemin que je cherche pour l'instant est celui de l'indexation de ces deux colonnes? pourrais je les indexer sans indexer les tables? et Comment pourrais je indexer des champs spatiales ?

[SQLpro]

Code :

1
2
CREATE INDEX X_GIS_loc_pol ON t_localisation_polygone USING GIST (lpo_geometry);
CREATE INDEX X_GIS_zon_hum ON tv_geom_zones_humides USING GIST (gez_geometry);

ATTENTION : la création de tels index sur une forte volumétrie peut demander plusieurs heures de travail. A ce terme vos requêtes seront probablement 1000 fois plus rapides...

A +

[nabil.brarou]

Merci SQLpro d'avoir répondu,
Justement par rapport aux index des champs géométriques, j'ai lu sur les index B-tree, R-tree et GIST laquelle de ces 3 vous parrait la plus pertinente en terme de rapidité d'accès aux champs géométriques.

[SQLpro]

Il n'y a pas le choix. Un index spatial est toujours GIST.

A +