¿Cómo optimizar una consulta ST_Within para contar las ocurrencias de rayos dentro de un país?

Question

Acabo de comenzar el aprendizaje de PostGIS, y ahora estoy tratando de contar el número de rayos en mi país (Brasil, en este caso).

Tengo las siguientes tablas:

earth_feed --> Esto es el geometry(Point, 4326), lon, lat y alguna otra información acerca de un determinado rayo ocurrencia.

brasil_shape --> Esta tabla tiene una única fila geometry(MultiPolygon, 4326) que es el conjunto de Brasil.

Mi consulta es para el 14 de enero (la tabla completa, es por Jan/2014, es una tabla de prueba)

SELECT COUNT(earth_feed.geom) FROM
earth_feed as earth, 
brasil_shape as brasil
WHERE 
EXTRACT('day' FROM date_occur) = 14 AND
ST_WITHIN(earth.geom, brasil.geom)

Esta consulta tarda unos 5 minutos para terminar, y para este día teníamos unos 200k rayo ocurrencias. También, los índices de la tabla parece estar bien:

CREATE INDEX idx_light_geom
  ON earth_feed
  USING gist
  (geom);

Así que tengo 2 preguntas:

1 - Se trata de un 'normal' tiempo de ejecución? Brasil tiene dimensiones continentales y una gran cantidad de los rayos incidentes.

2 - parece que el shapefile para el país de esquema es 'tirado' en cada comparación. He aquí parte de la EXPLIQUE de salida:

->  Nested Loop  (cost=0.00..9.58 rows=1 width=32)"
     ...
     ->  Seq Scan on brasil_shape brasil  (cost=0.00..1.01 rows=1 width=32)

Esta afirmación es correcta?

3 - El país de esquema es un MultiPolygon, entonces, ¿qué sucede si cambio de este shapefile de tener un menor tamaño de la cuadrícula (más polígonos)? Será el índice más eficaz? (No he probado aún).

Realmente agradezco si alguien me puede enseñar cómo optimizar este (si es posible claro). Gracias!

EDIT: Aquí está el completo EXPLICAR de salida (he cambiado los nombres para hacer el post easiear para leer)

"Aggregate  (cost=9.59..9.60 rows=1 width=32)"
"  ->  Nested Loop  (cost=0.00..9.58 rows=1 width=32)"
"        ->  Seq Scan on shape_brasil brasil  (cost=0.00..1.01 rows=1 width=32)"
"        ->  Index Scan using idx_raios_diario_jan_2014_geom on raios_diario_jan_2014 earth  (cost=0.00..8.56 rows=1 width=32)"
"              Index Cond: (earthnetworks_geometry_raios && brasil.geom)"
"              Filter: ((date_part('day'::text, earthnetworks_dt_horario) = 14::double precision) AND _st_contains(brasil.geom, earthnetworks_geometry_raios))"

Answer 1

Este es un ejemplo de tratando de hacer dos cosas a la vez. Desea índice espacial y temporalmente, pero sólo se puede utilizar un índice en un momento. Entonces usted necesita tomar algunas decisiones.

Si su restricción temporal es más restrictiva, debe crear un índice en la date_occur campo, y la moda de una consulta que utiliza-mediante el uso de un ENTRE el operador o un par de mayor igualdad y menos que alrededor de la meta fecha.

Si su componente espacial es más restrictiva, entonces tienes un problema de otro -- fragmentación del espacio. Aunque el índice espacial es encontrar todas las filas que están dentro de su búsqueda de la envolvente, el acto de unirse de nuevo a la tabla del índice es muy ineficiente (en esencia, un análisis completo de la tabla).

Hay muchas soluciones posibles a este, pero que implicar el cambio de la mesa:

1. Añadir un country_code campo a la tabla, luego de consultas con sólo los atributos (y quitar el índice espacial si se ralentiza el acceso)
2. Extraer todos los datos como una serie de consultas (o de primer orden, los límites políticos, o de un conjunto sistemático de la cuadrícula de azulejos), por lo que los vecinos filas son espacialmente co-localizados.
3. Si la tabla que sigue creciendo, realizar un mantenimiento regular para optimizar ventanas temporales (semana o mes) por componente espacial
4. Todos los de arriba

Answer 2

¿Has probado con ST_Intersects en lugar de ST_Within? Para los datos de puntos, debe devolver exactamente los mismos resultados (los puntos no pueden compartir solo una parte de su geometría con un polígono), pero la función en sí misma está mejor optimizada en el código PostGIS.