0

私の質問：

DROP TABLE IF EXISTS tmp;
CREATE TEMP TABLE tmp AS SELECT *, ST_BUFFER(the_geom::GEOGRAPHY, 3000)::GEOMETRY AS buffer FROM af_modis_master LIMIT 20000;
CREATE INDEX idx_tmp_the_geom ON tmp USING gist(buffer); 
EXPLAIN SELECT (DUMP(ST_UNION(buffer))).path[1], (DUMP(ST_UNION(buffer))).geom FROM tmp;

EXPLAINからの出力：

Aggregate  (cost=1705.52..1705.54 rows=1 width=32)
  ->  Seq Scan on tmp  (cost=0.00..1625.01 rows=16101 width=32)

Seq Scanは、インデックスを使用していないことを意味しますよね？なぜだめですか？

（この質問は最初にここに投稿されました：https ：//gis.stackexchange.com/questions/51877/postgis-query-not-using-gist-index-when-doing-a-st-dumpst-union 。ここのコミュニティははるかに活発なので、おそらくより迅速に答えを提供するでしょう。）

更新：バッファに基づいてフィルタリングするwhere句を追加しても、Seqスキャンが発生します。

ANALYZE tmp;
EXPLAIN SELECT (DUMP(ST_UNION(buffer))).path[1], (DUMP(ST_UNION(buffer))).geom FROM tmp WHERE ST_XMIN(buffer) = 0.0;
4

1 に答える 1

0

あなたのようなクエリは、インデックスを使用することはありません。これを行うと、テーブルのスキャンに相当するランダム ディスク I/O が (場合によっては通常のディスク I/O に加えて) 代用されます。

本質的に、基準を選択していないため、物理的な順序でディスクからデータを取得して処理するよりもインデックスが遅くなります。

ここで、インデックスが役立つ可能性のある where 条件を使用して単一の行のみをプルすると、テーブルの大きさに応じて、インデックスを使用するかどうかがわかる場合があります。非常に小さなテーブルではインデックスを使用することはありません。これは、追加のランダム ディスク I/O が有利になることは決してないためです。単一ページのシーケンシャル スキャンに勝るクエリ プランはないことを忘れないでください。

于 2013-04-26T14:28:39.547 に答える