Ganho de desempenho por meio do índice GIST para ponto na consulta de polígono

Eu tenho duas tabelas: localizações (id, region_id, the_geom) e regiões (id, the_geom). Para cada ponto de localização, desejo determinar a região em que está localizado:

UPDATE locations SET region_id = 
 (SELECT id FROM regions 
  WHERE ST_Within(locations.the_geom,regions.the_geom)
 );

Faz sentido criar um índice GIST nos pontos de localização? Vou criar um índice nos polígonos da região, mas não tenho certeza sobre os pontos. Isso aceleraria a consulta?

— underdark
fonte

Resposta curta: Não. Com este tipo de consulta UPDATE, estamos atualizando cada linha locations( "Seq Scan"), eo índice GiST em the_geomno regionsé suficiente para ajudar linhas-limite para a ST_Withincondição de par-up a linha desde regions.

Resposta mais longa: a mágica para descobrir isso é comparar o que você obtém da consulta de explicação . No pgAdmin III, existe um botão "Explain query" na parte superior de um editor de consultas, ou no pgsql, basta prefixar sua consulta com "explica":

postgis=# explain UPDATE locations SET region_id =
postgis-#  (SELECT id FROM regions
postgis(#   WHERE ST_Within(locations.the_geom, regions.the_geom)
postgis(#  );
                                         QUERY PLAN
--------------------------------------------------------------------------------------------
 Seq Scan on locations  (cost=0.00..8755.54 rows=1000 width=110)
   SubPlan 1
     ->  Index Scan using regions_gist_the_geom on regions  (cost=0.00..8.52 rows=1 width=4)
           Index Cond: ($0 && the_geom)
           Filter: _st_within($0, the_geom)
(5 rows)

Você não precisa entender tudo o que é tossido aqui. A principal coisa a ver aqui é na parte mais interna (SubPlan 1), indica "Índice" (= usa um índice, o que pode acelerar consideravelmente as coisas), e não "Seq Scan" (= verificação de sequência, ou seja, verificando cada linha para ver se está dentro, o que pode ser mais lento). Se você adicionar / excluir um índice GiST locations, a saída dessa consulta de explicação é exatamente a mesma, portanto, o desempenho da consulta deve ser o mesmo.

No entanto, se você fizer algo bobo e remover seu índice GiST regions, verá um plano de consulta diferente da mesma consulta acima:

                             QUERY PLAN
---------------------------------------------------------------------
 Seq Scan on locations  (cost=0.00..74288.00 rows=1000 width=110)
   SubPlan 1
     ->  Seq Scan on regions  (cost=0.00..74.05 rows=1 width=4)
           Filter: (($0 && the_geom) AND _st_within($0, the_geom))
(4 rows)

O importante a ser observado entre as duas consultas de explicação é o custo máximo estimado. Compare 74,05 aqui para 8,52 antes, portanto, você esperaria que essa consulta fosse mais lenta.

— Mike T
fonte