なぜPostgreSQLは簡単なクエリを作成するのが難しいのですか？

Question

私は今、私は単純なクエリ

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) 

と別の単純なクエリを行うインデックス

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

で25mln行 "Zemla" テーブルを持っていますインデックスが存在するとすぐに実行する必要があります

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

私が間違っていないと、ビットマップヒープスキャンはディスクからデータを取り出すアルゴリズムです。それは、エンジンが取り出すべきすべてのディスクページを分析し、最小のハードドライブヘッド移動のためにそれらをソートする。

テーブルが非常に大きく、ディスク上で非常に断片化する必要があるため、時間がかかります。あなたの2番目のクエリcount(*)については

---

、PostgreSQLはまだ、彼らが存在することを確認するために、結果の行を読み取る必要があります。他のデータベースシステムでは、この状況でインデックスを参照するだけで済む場合があります。詳細については、このページをチェックしてください：

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

---

テーブルの上にVACCUM FULLを試してみて、それが物事をスピードアップかどうかを確認します。