ポリゴンクエリのポイントのGISTインデックスによるパフォーマンスの向上

2つのテーブルがあります。locations（id、region_id、the_geom）とregions（id、the_geom）です。各ロケーションポイントについて、それが配置されているリージョンを特定します。

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

ロケーションポイントにGISTインデックスを作成することには意味がありますか？リージョンポリゴンにインデックスを作成しますが、ポイントについてはわかりません。クエリを高速化できますか？

— アンダーダーク
ソース

短い回答：いいえ。このタイプのUPDATEクエリでは、locations（ "Seq Scan"）の各行を更新します。条件の行を制限して、適切な行をペアにするthe_geomにregionsは、GiSTインデックスをオンにすれば十分です。ST_Withinregions

より長い答え：これを理解する魔法は、説明クエリから得られるものを比較することです。pgAdmin IIIからは、クエリエディターの上部に[クエリの説明]ボタンがあります。またはpgsqlからは、クエリの前に「説明」を付けるだけです。

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)

ここで咳き込んだすべてを理解する必要はありません。ここで確認する重要な点は、最も内側の部分（サブプラン1）にあり、「インデックス」（=インデックスを使用しているため、かなり高速化できる）であり、「シーケンススキャン」ではありません（=シーケンススキャン、つまり、それぞれをチェックしています）行内にあるかどうかを確認します。遅い場合があります）。でGiSTインデックスを追加または削除すると、locationsこのExplainクエリの出力はまったく同じになるため、クエリのパフォーマンスは同じになります。

ただし、馬鹿げたことをして、GiSTインデックスをから削除するとregions、上記と同じクエリから別のクエリプランが表示されます。

                             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)

2つのExplainクエリの間で確認する重要なことは、最大コストの見積もりです..ここでは74.05を8.52と比較しているため、このクエリは遅くなると予想されます。

— マイクT
ソース