Como se describe, la respuesta es "ninguna", por las siguientes razones:
- Tome una tabla espacial en 4326. Cree un índice espacial sobre ella. El índice espacial es un índice plano, que consiste en los límites 2D de las características, en 4326, ordenados en una estructura de árbol.
- (a) ejecute una consulta de filtro de distancia utilizando un reparto, como
ST_DWithin(geom::geography, %anothergeom, %radius)
. Debido a que la geografía está involucrada, el sistema buscará un índice de geografía (que se basa en una esfera, no en un plano) y no encontrará ninguno. Como no tiene índice, realizará la unión usando escaneos completos de las tablas. Será lento
- (b) ejecute una consulta de filtro de distancia utilizando una transformación, como
ST_DWithin(ST_Transform(geom, 2163), %anothergeom, %radius)
. Sus pruebas no están en contra de la columna indexada (geom), sino contra una función aplicada a la columna ( ST_Transform(geom,2163)
) y, de nuevo, su índice espacial no se utilizará. Será lento
Necesita que su consulta y su índice se armonicen. Si no desea cambiar la proyección de sus datos, deberá usar un índice funcional, por ejemplo, si crea un índice de geografía de función, puede usar una consulta basada en geografía:
CREATE INDEX mytable_geog_x
ON mytable USING GIST (geography(geom));
SELECT *
FROM mytable
WHERE ST_DWithin(geography(geom), %anothergeography, %radius);
O, en el caso de transformación:
CREATE INDEX mytable_geog_x
ON mytable USING GIST (ST_Transform(geom, 2163));
SELECT *
FROM mytable
WHERE ST_DWithin(ST_Transform(geom, 2163), %another2163geometry, %radius);
El rendimiento más rápido absoluto será si convierte los datos de su tabla en una proyección plana (como EPSG: 2163 ), crea un índice espacial y luego lo utiliza ST_DWithin()
en el resultado.
ALTER TABLE mytable
ALTER COLUMN geom
TYPE Geometry(Point, 2163)
USING ST_Transform(geom, 2163);
CREATE INDEX mytable_geom_x ON mytable USING GIST (geom);
SELECT *
FROM mytable
WHERE ST_DWithin(geom, %some2163geom, %radius)