Por qué es más rápido que el st_intersects &&

Question

Es una tabla de puntos. ~ Registros de 1M

SELECT COUNT(*) as value FROM alasarr_social_mv s; 
Output: 976270

Parece que st_intersects fuerzas para utilizar los índices espaciales pero & & no.

De la muestra usando ST_Intersects (282ms)

SELECT COUNT(*) as value
FROM alasarr_social_mv 
WHERE ST_Intersects(
  the_geom_webmercator, 
  ST_MakeEnvelope(-410961,4920492,-402305,4926887,3857)
)


Aggregate  (cost=34370.18..34370.19 rows=1 width=0) (actual time=282.715..282.715 rows=1 loops=1)
  ->  Bitmap Heap Scan on alasarr_social_mv s  (cost=5572.17..34339.84 rows=60683 width=0) (actual time=21.574..240.195 rows=178010 loops=1)
        Recheck Cond: (the_geom_webmercator && '0103000020110F0000010000000500000000000000441519C1000000002BC5524100000000441519C1000000C069CB524100000000048E18C1000000C069CB524100000000048E18C1000000002BC5524100000000441519C1000000002BC55241'::geometry)
        Filter: _st_intersects(the_geom_webmercator, '0103000020110F0000010000000500000000000000441519C1000000002BC5524100000000441519C1000000C069CB524100000000048E18C1000000C069CB524100000000048E18C1000000002BC5524100000000441519C1000000002BC55241'::geometry)
        Heap Blocks: exact=4848
        ->  Bitmap Index Scan on alasarr_social_mv_gix  (cost=0.00..5569.13 rows=182050 width=0) (actual time=20.836..20.836 rows=178010 loops=1)
              Index Cond: (the_geom_webmercator && '0103000020110F0000010000000500000000000000441519C1000000002BC5524100000000441519C1000000C069CB524100000000048E18C1000000C069CB524100000000048E18C1000000002BC5524100000000441519C1000000002BC55241'::geometry)
Planning time: 0.192 ms
Execution time: 282.758 ms

De la muestra usando && (414ms)

SELECT COUNT(*) as value
FROM alasarr_social_mv  
WHERE the_geom_webmercator && 
  ST_MakeEnvelope(-410961,4920492,-402305,4926887,3857)

Aggregate  (cost=22535.97..22535.97 rows=1 width=0) (actual time=414.314..414.314 rows=1 loops=1)
  ->  Seq Scan on alasarr_social_mv  (cost=0.00..22444.94 rows=182050 width=0) (actual time=0.017..378.427 rows=178010 loops=1)
        Filter: (the_geom_webmercator && '0103000020110F0000010000000500000000000000441519C1000000002BC5524100000000441519C1000000C069CB524100000000048E18C1000000C069CB524100000000048E18C1000000002BC5524100000000441519C1000000002BC55241'::geometry)
        Rows Removed by Filter: 798260
Planning time: 0.134 ms
Execution time: 414.343 ms

Versión de PostGIS

POSTGIS="2.2.2" GEOS="3.5.0-CAPI-1.9.0 r4084" PROJ="Rel. 4.8.0, 6 March 2012" GDAL="GDAL 1.11.0, released 2014/04/16" LIBXML="2.7.8" LIBJSON="UNKNOWN" (core procs from "2.2.2" need upgrade) RASTER (raster procs from "2.2.2" need upgrade) – alasarr 2 mins ago

Answer 1

Este tipo de hallazgo viene bastante a menudo, y es un poco oscuro, así que vale la pena rescatarlo. Si se define una geometría dentro de una función que utiliza, tales como ST_Intersects o && (que ST_Intersects utiliza bajo el capó), entonces el planificador de consultas elige un análisis completo de la tabla, como "que" no tiene conocimiento de los resultados de la creación de geometría de la función, es decir, ST_MakeEnvelope en este caso.. Si se define la geometría que desee comprobar intersección en un CTE, a continuación, el optimizador está tratando con una cantidad conocida, y hará uso de un índice espacial, si está disponible.

Así, rewritting su consulta como:

WITH test_geom (geom) AS 
   (SELECT ST_MakeEnvelope(-410961,4920492,-402305,4926887,3857))
  SELECT COUNT(*) as value
    FROM alasarr_social_mv mv, test_geom tg 
   WHERE ST_Intersects(mv.the_geom_webmercator, tg.geom)

ahora uso un índice espacial. Del mismo modo, && ahora el uso de un índice para comprobar un cuadro delimitador, y, (mientras que no se puede probar en contra de sus datos), debe ser más rápido que ST_Intersects.

Curiosamente, en su consulta, ST_Intersects es el uso de un mapa de bits de escaneo (no un gist) índice, mientras que && es el uso de ningún índice. Así, tanto las consultas será más rápido con el CTE, pero && ahora debe ser más rápida que la ST_Intersects.

No hay más explicación de lo que está pasando en esta pregunta y sus respuestas/comentarios.

EDIT: Para hacer esto explícito, si miramos la definición de ST_Intersects en postgis.sql (que es llamado por CREATE EXTENSION postgis y se encuentra en el directorio contrib de su Postgres instalar), verá:

---- Inlines index magic
CREATE OR REPLACE FUNCTION ST_Intersects(geom1 geometry, geom2 geometry)
    RETURNS boolean
    AS 'SELECT $1 OPERATOR(&&) $2 AND _ST_Intersects($1,$2)'
    LANGUAGE 'sql' IMMUTABLE ;

incluyendo el comentario: inline índice de magia.