使用されていないがクエリに影響を与えるインデックス

いくつかの数値といくつかの追加データを含むPostgreSQL 9.3テーブルがあります。

CREATE TABLE mytable (
    myid BIGINT,
    somedata BYTEA
)

このテーブルには現在約1,000万のレコードがあり、1GBのディスク容量を使用します。myid連続していません。

100000の連続番号の各ブロックにある行の数を計算したいと思います。

SELECT myid/100000 AS block, count(*) AS total FROM mytable GROUP BY myid/100000;

これは約3500行を返します。

クエリプランでまったく言及されていなくても、特定のインデックスが存在すると、このクエリが大幅に高速化されることに気づきました。インデックスなしのクエリプラン：

db=> EXPLAIN (ANALYZE TRUE, VERBOSE TRUE) SELECT myid/100000 AS block, count(*) AS total FROM mytable GROUP BY myid/100000;
                                                               QUERY PLAN                                                               
----------------------------------------------------------------------------------------------------------------------------------------
 GroupAggregate  (cost=1636639.92..1709958.65 rows=496942 width=8) (actual time=6783.763..8888.841 rows=3460 loops=1)
   Output: ((myid / 100000)), count(*)
   ->  Sort  (cost=1636639.92..1659008.91 rows=8947594 width=8) (actual time=6783.752..8005.831 rows=8947557 loops=1)
         Output: ((myid / 100000))
         Sort Key: ((mytable.myid / 100000))
         Sort Method: external merge  Disk: 157440kB
         ->  Seq Scan on public.mytable  (cost=0.00..236506.92 rows=8947594 width=8) (actual time=0.020..1674.838 rows=8947557 loops=1)
               Output: (myid / 100000)
 Total runtime: 8914.780 ms
(9 rows)

インデックス：

db=> CREATE INDEX myindex ON mytable ((myid/100000));
db=> VACUUM ANALYZE;

新しいクエリプラン：

db=> EXPLAIN (ANALYZE TRUE, VERBOSE TRUE) SELECT myid/100000 AS block, count(*) AS total FROM mytable GROUP BY myid/100000;
                                                            QUERY PLAN                                                            
----------------------------------------------------------------------------------------------------------------------------------
 HashAggregate  (cost=281242.99..281285.97 rows=3439 width=8) (actual time=3190.189..3190.800 rows=3460 loops=1)
   Output: ((myid / 100000)), count(*)
   ->  Seq Scan on public.mytable  (cost=0.00..236505.56 rows=8947485 width=8) (actual time=0.026..1659.571 rows=8947557 loops=1)
         Output: (myid / 100000)
 Total runtime: 3190.975 ms
(5 rows)

したがって、クエリプランとランタイムは大幅に（ほぼ3倍）異なりますが、どちらもインデックスについては言及していません。この動作は、私の開発マシンで完全に再現可能です。インデックスを削除し、クエリを数回テストし、インデックスを再作成し、再度クエリを数回テストするというサイクルを数回行いました。ここで何が起こっているのですか？

VACUUM ANALYZEあなたの例で違いを生みます。さらに、@ jjanesが提供したように、関数インデックスの追加の統計。ドキュメントごと：

pg_statisticインデックス式の値に関する統計データも格納します。これらは、実際のデータ列であるかのように記述されます。特に、starelidインデックスを参照します。ただし、基になるテーブル列のエントリと重複するため、通常の非式インデックス列のエントリは作成されません。

ただし、インデックスを作成するだけでは、Postgresは統計を収集しません。試してください：

CREATE INDEX myindex ON mytable ((myid/100000));
SELECT * FROM pg_statistic WHERE starelid = 'myindex'::regclass;

最初に実行するANALYZE（またはVACUUM ANALYZE、またはautovacuumデーモンが起動する）までは何も返しません。

ANALYZE mytable;
SELECT * FROM pg_statistic WHERE starelid = 'myindex'::regclass;

追加された統計が表示されます。

とにかくテーブル全体を読み取る必要があるので、Postgresは、計算がmyid/100000切り替えに十分なコストがかかると予想しない限り、順次スキャンを使用します。

他の唯一のチャンスは、インデックスがテーブルよりもはるかに小さい場合、インデックスのみのスキャンであり、インデックスのみのスキャンの前提条件が満たされます。詳細はPostgres Wikiとマニュアルにあります。

その機能的指標が使用されない限り、追加された統計による付随的な利益は中程度です。テーブルが読み取り専用の場合、コストは低くなりますが、再び、おそらくインデックスのみのスキャンがすぐに表示されます。

より高い統計目標をに設定することで、より良いクエリプランを達成できる場合もありますmytable.myid。それはわずかなコストしかかかりません。もっと：

• PostgreSQL +クエリプランナー+エンティティの量

式インデックスを作成すると、PostgreSQLはその式に関する統計を収集します。これらの統計が手元にあるため、クエリが返す集計行数の正確な見積もりが得られるため、より適切なプランを選択できます。

特にこの場合、追加の統計がなければ、ハッシュテーブルが大きすぎてwork_memに収まらないと考えたため、その方法を選択しませんでした。