3

私のテーブルは次のとおりです（他にもいくつかの列があります）：

id INTEGER
amount INTEGER

に索引がありますamount。クエリは次のとおりです。

explain analyze select count(amount) from receipt

出力は次のとおりです。

Aggregate  (cost=215856.23..215856.23 rows=1 width=4) (actual time=180209.785..180209.787 rows=1 loops=1)
  ->  Index Only Scan using idx_amount on receipt  (cost=0.00..215046.23 rows=1620001 width=4) (actual time=0.109..177443.189 rows=2584317 loops=1)
        Heap Fetches: 2316761
Total runtime: 180209.868 ms

どうしたの？ここで説明されているように、インデックスのみのスキャンが使用され、リクエストを最適化することになっています。なぜ遅いのですか？

4

2 に答える 2

3

analyzeを介して統計を更新してみてください。推定行数 (1.620.001) と実際の行数 (2.584.317) を比較すると、オプティマイザが正しく機能していないことがわかります。

于 2013-09-14T10:04:34.437 に答える
2

この特定の問題 (heap fetchesカウントが多いことに注意してください) はwikiで説明されているようです:

可視性のバキュームとインデックスのみのスキャンの問題:

9.2 の時点で、可視性マップにページを追加して、インデックスのみのスキャンを有効にすることには大きな利点があります。ただし、これはいずれにせよバキュームされたページに対してのみ行われるため、ユーザーが手動で VACUUM を呼び出さない限り、更新も削除もされていないページはすべて可視に設定されません。これにより、インデックス オンリー スキャンの有用性が低下します。

于 2013-09-14T10:23:56.183 に答える