爲什麼PostgreSQL爲簡單查詢做了這麼難的計劃？

我有一個25mln行「Zemla」表與索引爲什麼PostgreSQL爲簡單查詢做了這麼難的計劃？

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運算符的查詢具有位圖堆掃描。我的查詢既沒有也沒有AND運算符

來源

2017-03-15 alexey2baranov

「硬計劃」是什麼意思？向我們展示使用'explain（analyze）'生成的執行計劃，而不是一個簡單的解釋。 –

固定問題解釋（分析） – alexey2baranov

行估計是相當關閉。運行'真空分析「Zemla」'改變什麼？ –