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