为什么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”'改变什么？ –