¿Cómo solucionar el problema de rendimiento en PostGIS ST_Intersects?

Question

Soy un novato en postgis y tengo un problema en el rendimiento de las consultas.

Esta mi consulta:

SELECT DISTINCT ON (userid) userid ,ST_AsText(position), timestamp  
FROM table1 
WHERE ST_Intersects ( ST_GeomFromText('a multiypolygon geom goes here',4326),position) 
ORDER BY userid, timestamp desc

y el problema es mi multipolygon son muy grandes polígonos (600 páginas de largo en word doc!) y tardó más de 2 horas para ejecutar!

¿Hay una manera de optimizar mi consulta o utilizar de otra manera?

¡Por favor su ayuda es muy apreciada!

Answer 1

Lo que debes hacer es poner su multipolygon grande en una tabla como polígonos individuales (con ST_Dump) y poner un índice en ella. Algo así como:

CREATE TABLE big_polygon as
SELECT (ST_Dump( ST_GeomFromText('a multiypolygon geom goes here',4326))).geom as geom;

-- It is always great to put a primary key on the table
ALTER table big_polygon ADD Column gid serial PRIMARY KEY;

-- Create the index
CREATE INDEX idx_big_polygon_geom
on big_polygon
USING gist(geom);

-- To give the database some information about how the index looks
analyze big_polygon;

-- Then you go:
SELECT DISTINCT ON (userid) userid ,ST_AsText(position), timestamp  
FROM table1, big polygon WHERE ST_Intersects ( big_polygon.geom,position) 
ORDER BY userid, timestamp desc;

Debe de manera más rápida por varias razones.

HTH

Nicklas

Answer 2

Depende de qué tipo de calidad - precisión que usted necesita. Usted, evidentemente, puede simplificar los polígonos mediante: http://postgis.net/docs/ST_Simplify.html

Lo que me hizo a menudo durante el desarrollo de mi aplicación de SIG era pensar en la mejor manera de minimizar los datos. Por ejemplo. preselección de los polígonos dentro de los límites del cuadro, por ejemplo. - Dependiendo de zoomlevel no necesita de ultra precisión de los resultados (st_simplify), etc...

Espero que los haya ayudado un poco!

Answer 3

Dependiendo de su postgres y/o sql experiencia que usted tiene varias opciones:

1. analizar la consulta a través de la EXPLICAR comando para saber si usted está golpeando a un particular cuello de botella. Advertencia: a veces el resultado de EXPLICAR puede ser difícil de entender

2. si usted espera que la mayoría o una parte significativa de las geometrías en la tabla1 ¿ NO cruzan la multipolígono usted podría tratar de aplicar una condición preliminar en contra de un polígono más simple (es decir, por la rotura de la multiploygon en trozos más pequeños) y, a continuación, ejecute el más pesado de multipolygon intersección sólo en los resultados. A continuación verá un ejemplo.

3. si y sólo si la CPU es el cuello de botella (es decir, el servidor está atascado computación intersecciones) I debidamente sugieren que usted reciba una más grande, más rápido, más potente CPU o alquiler de un tiempo de CPU de Alto rendimiento Instancia de Amazon EC2 y destruirlo cuando hayas terminado

Ejemplo de consulta para el punto 2:

SELECT DISTINCT ON (st1.userid) st1.userid ,ST_AsText(st1.position), st1.timestamp  
FROM (
    select userid, position, timestamp from table1 
    WHERE ST_Intersects ( YOUR_MULTIPOL_BOUNDS_HERE,position)
) as st1 
WHERE ST_Intersects ( ST_GeomFromText('a multiypolygon geom goes     here',4326),st1.position) 
ORDER BY st1.userid, st1.timestamp desc

Para mejorar el rendimiento también puede temporalmente se materializan subselección st1 como una tabla, lo que permite índice.

@Nicklas es correcto señalar que en los comentarios que ejemplo para la sugerencia 2 en caso de no ayudar. Está en lo cierto, pero creo que estoy (en parte) a la derecha.

De hecho parece una muy similar pregunta (y contestar), apenas el pasado mes de noviembre en el postgis ML:

http://postgis.refractions.net/pipermail/postgis-users/2011-November/031344.html

y resulta que la sugerencia es para romper el polígono de modo que el índice de la manera más eficaz de filtrar los falsos intersecciones que de lo contrario sería provocada por un simple límite de verificación.