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;

解释的输出:

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 Scan:

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 回答