Guadagno delle prestazioni tramite l'indice GIST per la query Point in Polygon

Ho due tabelle: posizioni (id, region_id, the_geom) e regioni (id, the_geom). Per ogni punto di località che voglio determinare la regione in cui si trova:

UPDATE locations SET region_id = 
 (SELECT id FROM regions 
  WHERE ST_Within(locations.the_geom,regions.the_geom)
 );

Ha senso costruire un indice GIST sui punti posizione? Costruirò un indice sui poligoni della regione ma non sono sicuro dei punti. Accelererebbe la query?

— underdark
fonte

Risposta breve: No. Con questo tipo di query UPDATE, stiamo aggiornando ogni riga in locations("Scansione Seq") e l'indice GiST su the_geomin regionsè sufficiente per aiutare a limitare le righe per la ST_Withincondizione da cui accoppiare la riga giusta regions.

Risposta più lunga: la magia per capire questo è confrontare ciò che si ottiene dalla spiegazione della query . Da pgAdmin III, c'è un pulsante "Spiega query" nella parte superiore di un editor di query, o da pgsql, basta aggiungere il prefisso alla query con "spiegazione":

postgis=# explain UPDATE locations SET region_id =
postgis-#  (SELECT id FROM regions
postgis(#   WHERE ST_Within(locations.the_geom, regions.the_geom)
postgis(#  );
                                         QUERY PLAN
--------------------------------------------------------------------------------------------
 Seq Scan on locations  (cost=0.00..8755.54 rows=1000 width=110)
   SubPlan 1
     ->  Index Scan using regions_gist_the_geom on regions  (cost=0.00..8.52 rows=1 width=4)
           Index Cond: ($0 && the_geom)
           Filter: _st_within($0, the_geom)
(5 rows)

Non hai bisogno di capire tutto ciò che viene tossito qui. La cosa chiave da vedere qui è nella parte più interna (Sottopiano 1) indica "Indice" (= usa un indice, che potrebbe velocizzare notevolmente le cose), e non "Scansione Seq" (= scansione sequenziale, cioè controllando ogni riga per vedere se è all'interno, che può essere più lento). Se aggiungi / elimini un indice GiST locations, l'output di questa query di spiegazione è esattamente lo stesso, quindi le prestazioni della query dovrebbero essere le stesse.

Tuttavia, se fai qualcosa di stupido e rimuovi il tuo indice GiST regions, vedrai un piano di query diverso dalla stessa query di cui sopra:

                             QUERY PLAN
---------------------------------------------------------------------
 Seq Scan on locations  (cost=0.00..74288.00 rows=1000 width=110)
   SubPlan 1
     ->  Seq Scan on regions  (cost=0.00..74.05 rows=1 width=4)
           Filter: (($0 && the_geom) AND _st_within($0, the_geom))
(4 rows)

La cosa importante da vedere tra le due query di spiegazione è la stima dei costi massimi. Contrasto 74.05 qui a 8.52 prima, quindi ti aspetteresti che questa query sia più lenta.

— Mike T
fonte