왜 PostgreSQL은 간단한 쿼리를 그렇게 어렵게 계획합니까? 인덱스

Question

가 나는 25mln 행이 "Zemla"테이블

CREATE INDEX zemla_level 
    ON public."Zemla" 
    USING btree 
    (level); 

지금 내가 할 간단한 쿼리

select * from "Zemla" where level = 7 

얻을 열심히 쿼리 계획

Bitmap Heap Scan on "Zemla" (cost=18316.26..636704.15 rows=978041 width=181) (actual time=216.681..758.663 rows=975247 loops=1) 
    Recheck Cond: (level = 7) 
    Heap Blocks: exact=54465 
    -> Bitmap Index Scan on zemla_level (cost=0.00..18071.74 rows=978041 width=0) (actual time=198.041..198.041 rows=1949202 loops=1) 
     Index Cond: (level = 7) 

다른 간단한 쿼리하는 인덱스는 내가 생각할 때 즉시 실행해야합니다.

select count(*) from "Zemla" where level = 7 

Aggregate (cost=639149.25..639149.26 rows=1 width=0) (actual time=1188.366..1188.366 rows=1 loops=1) 
    -> Bitmap Heap Scan on "Zemla" (cost=18316.26..636704.15 rows=978041 width=0) (actual time=213.918..763.833 rows=975247 loops=1) 
     Recheck Cond: (level = 7) 
     Heap Blocks: exact=54465 
     -> Bitmap Index Scan on zemla_level (cost=0.00..18071.74 rows=978041 width=0) (actual time=195.409..195.409 rows=1949202 loops=1) 
       Index Cond: (level = 7) 

제 질문은 PostgreSQL이 첫 번째 인덱스 스캔 이후에 너무 많은 오버 헤드로 다른 비트 맵 힙 스캔을하는 이유입니다.

편집 : What is a "Bitmap heap scan" in a query plan?은 OR 연산자가있는 일부 쿼리가 비트 맵 힙 스캔을 갖는 이유에 대한 대답이기 때문에 다른 질문입니다. 내 검색어가 OR 또는 AND 연산자가 아닙니다.

Answer 1

내가 잘못하지 않으면 비트 맵 힙 스캔은 디스크에서 데이터를 가져 오는 알고리즘입니다. 엔진이 가져와야하는 모든 디스크 페이지를 분석하여 최소한의 하드 드라이브 헤드 이동을 위해 정렬합니다.

테이블 크기가 매우 커서 디스크에 조각이 많이 들어 있어야하기 때문에 시간이 오래 걸립니다.

두 번째 쿼리 count(*)를 들어

---

, PostgreSQL는 여전히 존재하는지 확인 결과 행을 읽을 필요합니다; 다른 데이터베이스 시스템은이 상황에서 색인을 참조하기 만하면됩니다. 자세한 내용은이 페이지를 확인 :

https://wiki.postgresql.org/wiki/Index-only_scans

---

는 테이블에 VACCUM FULL을 시도하고 그 일을 속도되는지 확인합니다.