PostGIS와 쿼리 ST_DUMP을 할 때 요점 인덱스를 사용하지 않는 (ST_Union은

Question

내 쿼리에서

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) 

서열 스캔은 인덱스를 사용하여 바로 왜되지 않음을 의미 ?

(이 질문은 처음 게시 된 사람 : https://gis.stackexchange.com/questions/51877/postgis-query-not-using-gist-index-when-doing-a-st-dumpst-union) 여기 다시 게시하는 것에 대한 사과는 훨씬 활성화되어 있으므로 답변을 빨리 제공 할 수 있습니다.

UPDATE : 심지어 버퍼에 기반 필터 절은 서열 스캔이 발생 어디를 추가 :

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

Answer 1

당신 같은 쿼리 적 인덱스를 사용하지 않습니다 있습니다. 이렇게하려면 테이블 스캔을 위해 상당한 임의의 디스크 I/O (보통 디스크 I/O 외에)를 대체하십시오.

본질적으로 기준에서 선택하지 않으므로 물리적 순서로 디스크에서 데이터를 가져 와서 처리하는 것보다 색인 속도가 느려집니다.

인덱스가 도움이 될 수있는 where 조건으로 단일 행을 가져온 경우 테이블의 크기에 따라 인덱스를 사용할 수도 있고 사용하지 않을 수도 있습니다. 여분의 디스크 I/O가 결코 승리하지 못하기 때문에 아주 작은 테이블은 인덱스를 사용하지 않습니다. 단일 페이지를 통한 순차적 검색보다 질의 계획이 더 중요하지 않음을 기억하십시오 ....