Ganancia de rendimiento a través del índice GIST para el punto en la consulta de polígono

Tengo dos tablas: ubicaciones (id, region_id, the_geom) y regiones (id, the_geom). Para cada punto de ubicación, quiero determinar la región en la que se encuentra:

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

¿Tiene sentido construir un índice GIST en los puntos de ubicación? Construiré un índice sobre los polígonos de la región, pero no estoy seguro acerca de los puntos. ¿Aceleraría la consulta?

— bajo oscuro
fuente

Respuesta corta: No. Con este tipo de consulta UPDATE, estamos actualizando cada fila locations( "Sec Scan"), y el índice de GiST the_geomen regionses suficiente para ayudar a las filas límite para la ST_Withincondición de par en marcha la fila derecha desde regions.

Respuesta más larga: la magia para resolver esto es comparar lo que obtienes de la consulta de explicación . Desde pgAdmin III, hay un botón "Explicar consulta" en la parte superior de un editor de consultas, o desde pgsql, solo prefija su consulta con "explicar":

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)

No es necesario que comprenda todo lo que se dice aquí. La clave para ver aquí está en la parte más interna (Subplan 1) indica "Índice" (= usa un índice, lo que podría acelerar las cosas considerablemente), y no "Seq Scan" (= exploración de secuencia, es decir, comprobar cada fila para ver si está dentro, que puede ser más lento). Si agrega / elimina un índice GiST locations, el resultado de esta consulta explicativa es exactamente el mismo, por lo que el rendimiento de la consulta debería ser el mismo.

Sin embargo, si hace algo tonto y elimina su índice GiST regions, verá un plan de consulta diferente de la misma consulta que anteriormente:

                             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)

Lo importante que hay que ver entre las dos consultas explicativas es la estimación del costo máximo ... contraste 74.05 aquí con 8.52 antes, por lo que esperaría que esta consulta sea más lenta.

— Mike T
fuente