PostgreSQL / PostGIS空間インデックス-スピードアップなし

PostgreSQL / PostGISデータベースに空間テーブルがあります。その中のすべての行はポリゴンを表します。次の形式です。

+----+--------+
|gid |   way  |
+----+--------+
|241 | 01030..|

幾何学的列は、ポリゴンのジオメトリを含む「ウェイ」です。WKTでは、POLYGON（（ '....'））です。2つのポリゴンが相互に含まれているかどうかをテストするために、このテーブルで多くのST_Containsクエリを実行しています：

Select ST_Contains(a.way, b.way) From table AS a, table AS b Where a.gid = 15 And b.gid = 16

このクエリを高速化する方法を疑問に思っていて、テーブルに空間インデックスを追加しました。

CREATE INDEX table_way_gist ON table USING gist(way);

しかし、実際にはスピードアップは見られません。ST_Containsクエリを実行する前に、テーブルにすべてのポリゴンを入力した後、インデックスを作成します。テーブルを埋める前にインデックスを追加する必要がありますか？インデックスを操作するためのテーブルには特別な要件がありますか？幾何学的列のウェイの投影（srid）は900913に設定されます。

私は使用しています：psql（PostgreSQL）9.1.4 / POSTGIS = "1.5.3"

あなたの質問で表現されたクエリの最も効率的なインデックスは、where式に現れる唯一の列なので、gidのインデックスです：

 CREATE INDEX table_gid ON table (gid);

gistインデックスはスペースのみを消費し、挿入/更新/削除が遅くなるため、安全に削除できます。

長い説明

先ほど述べたように、あなたのケースで最も効果的なインデックスはgid上のインデックスです。dbエンジンが行をより速く取得できるためです（通常、取得はプロセスの最も遅い部分です）。その後、おそらくより良い結果を計算します

  ST_Contains(a.way, b.way)

インデックスを見ないでの圧迫。その理由は、クエリプランナはおそらく見上げるの余分なコストと推定されることである主旨の両方の列のインデックス対見上げa.wayとb.way行の合計数は、ルックアップするように直接値が努力する価値はありません特にインデックスが一意である場合は、おそらく非常に小さいです。

経験則として、プランナーはおそらく小さなデータセットのインデックススキャンよりもテーブルスキャンを好むことを覚えておいてください（データセットのサイズはテーブルの統計を調べることで推定されます）。

unicolettiが言ったように、ジオメトリ列の要旨インデックスは、WHERE式でST_Contains（）を使用する場合にのみ機能します。

たとえば、互いに含まれるすべてのポリゴンを知りたい場合は、次のようなものを使用できます。

SELECT a.gid, b.gid
FROM table AS a, table as b
WHERE a.gid != b.gid and ST_Contains(a.way, b.way)

この場合、テーブルのサイズとジオメトリの複雑さに応じて、ST_Containsは完全なジオメトリを実際にチェックする前に境界ボックスを比較してポリゴンをフィルタリングすることから開始するため、gistインデックスは大幅に高速化する必要があります。OpenGeoチュートリアルで簡単な説明を見ることができます。