Índices espaciales en PostGIS: mida antes de optimizar

Un índice espacial reduce candidatos; no evita todo el trabajo geométrico. La mejora depende de la distribución, selectividad, caché y consulta. No publique un porcentaje de aceleración sin datos, hardware y procedimiento reproducibles. El laboratorio siguiente genera puntos sintéticos y compara planes.

Prepare un conjunto controlado

Use una base de pruebas con PostGIS. El SQL crea una tabla temporal que desaparece al cerrar la sesión y no representa ubicaciones reales.

CREATE TEMP TABLE bench_points AS
SELECT i AS id,
       ST_SetSRID(ST_MakePoint((i % 1000)::double precision,
                              (i / 1000)::double precision), 3857) AS geom
FROM generate_series(1, 100000) AS i;
EXPLAIN (ANALYZE, BUFFERS)
SELECT count(*) FROM bench_points
WHERE ST_DWithin(geom, ST_SetSRID(ST_MakePoint(500,50),3857), 10);
CREATE INDEX bench_points_gix ON bench_points USING gist (geom);
ANALYZE bench_points;
EXPLAIN (ANALYZE, BUFFERS)
SELECT count(*) FROM bench_points
WHERE ST_DWithin(geom, ST_SetSRID(ST_MakePoint(500,50),3857), 10);

EXPLAIN ANALYZE ejecuta la consulta. Úselo aquí sobre datos desechables; no lo aplique a una escritura operativa sin comprender sus efectos. Compare filas devueltas, filas descartadas, buffers y tiempo, no solo el nombre del índice.

Interprete el plan

Es posible que PostgreSQL elija un recorrido secuencial para una tabla pequeña o una consulta que devuelve gran parte de ella. Eso no demuestra un fallo del índice. Cambie el radio y observe cómo varía la selectividad. Repita varias veces y distinga la primera lectura de las posteriores con caché.

ST_DWithin permite aprovechar índices para seleccionar proximidad. Aplicar una transformación a cada geometría de la columna puede impedir usar el índice simple sobre esa columna. Si necesita consultas frecuentes en otro CRS, evalúe una columna preparada o un índice de expresión que coincida con la consulta; mida el costo de almacenamiento y actualización.

Precisión y unidades

El ejemplo usa coordenadas sintéticas en EPSG:3857 para ilustrar el plan, no para medir distancias oficiales. En un proyecto real elija una proyección adecuada o geography según el caso y construya el índice correspondiente. Un cálculo rápido con unidades equivocadas sigue siendo incorrecto.

Mantenga estadísticas después de cargas importantes y observe consultas reales antes de crear índices adicionales. Cada índice consume almacenamiento y aumenta trabajo de escritura. Pruebe filtros por atributos junto con filtros espaciales, porque la mejor estrategia puede combinar varios índices.

Evidencia de mejora

Conserve consulta, tamaño del conjunto, versión, plan y resultados de varias ejecuciones. La salida funcional debe ser idéntica antes y después. Si cambia la cantidad de entidades o el criterio de inclusión en el límite, no está midiendo solamente rendimiento. Valide luego con una copia representativa y concurrencia semejante a la prevista.

Leer el plan como una secuencia de decisiones

Comienza por la corrección: registra conteo exacto y casos de borde. Compara filas estimadas por PostgreSQL con filas realmente procesadas. Una diferencia grande sugiere revisar estadísticas o distribución. Identifica si el tiempo se consume buscando candidatos, comprobando geometrías, ordenando, transfiriendo filas o serializando fuera de la base.

El índice puede acelerar candidatos mientras el mapa sigue lento porque solicita demasiada geometría. Mide por separado ejecución de base, serialización del servicio, bytes de respuesta y renderizado. Son cuellos de botella distintos.

Ejecutar una matriz útil de experimentos

Sobre la misma tabla sintética, repite con radios 1, 10 y 100. Conserva punto, configuración y resto de consulta. Repite cada caso varias veces y distingue la primera ejecución. El ejercicio explora selectividad y caché; no compares sus tiempos con un servicio Esri para declarar ganador entre productos.

Reporta medianas y rangos cuando haya suficientes ejecuciones. Conserva mediciones originales en lugar de elegir la más rápida. Para una meta operacional, acuerda presupuesto de respuesta con el responsable y mide concurrencia esperada; una consulta aislada no lo demuestra.

Mantener reconocible la columna indexada

Si la tabla guarda geometría métrica con GiST y recibe longitud y latitud, transformar la geometría pequeña de consulta al CRS de la tabla puede permitir reutilizar el índice. Transformar cada objeto almacenado puede exigir un índice de expresión u otro plan. Comprueba el plan real; no infieras uso del índice por la apariencia del SQL.

Calcular ST_Distance para toda la tabla y filtrar después puede requerir más trabajo que aplicar primero un predicado espacial adecuado. Obtén candidatos acotados y calcula luego valores exactos de presentación. Revisa orden y empates al buscar el objeto más cercano.

Diagnosticar en la capa correcta

Después de cada cambio, repite controles de corrección. Simplificar geometría o usar teselas puede mejorar el mapa y cambiar su contrato. Separa geometría analítica y de visualización cuando importen medidas exactas. Continúa con teselas vectoriales y PMTiles.

Referencia: planificación de consultas espaciales PostGIS.

Fuentes y documentación

• PostGIS reference
• PostgreSQL documentation
• ST_DWithin

Siguiente paso

Continúe en la colección Open GIS. Para comparar un proyecto concreto, use la calculadora de costo total y solicite una evaluación.

Lecturas relacionadas

• Cargar datos en PostGIS con GDAL: staging y validación antes de publicar
• PostGIS multiusuario: permisos, esquemas y edición concurrente