Vacuum Is a Lie: About Your Indexes

よくある誤解

「VACUUM（または VACUUM FULL）を実行すれば PostgreSQL が健全に保たれる」という広まった考えがあります。
死んだタプルが除去され、トランザクション ID が再利用され、スペースが回収されると信じられていますが、実際には VACUUM はインデックスの膨張を解消しません。
それはヒープ（テーブル）のデータのみを掃除しており、B‑tree 構造自体はそのままです。

ストレージ構成

VACUUM が異なる理由

• ヒープでは、VACUUM はページ内の行を詰め直し、空きページを回収できる。
• インデックスでは 「死んだインデックスエントリだけを削除」 する。
  • 空きページを完全に削除して再利用可能にすることはない。
  • 木構造の深さを減らしたり、物理的な B‑tree 配置を変えたりしない。

ヒープはテトリスみたいだが、インデックスは並べ替え済みの本棚のようです。VACUUM は本を取り出すだけで、残ったものをまとめ直せません。

実験

CREATE EXTENSION IF NOT EXISTS pgstattuple;
CREATE TABLE demo (id integer PRIMARY KEY, data text);

-- 100 000 行
INSERT INTO demo(id, data)
SELECT g, 'Row number '||g||' with some extra data'
FROM generate_series(1,100000) g;

ANALYZE demo;

ベースライン

SELECT relname,
       pg_size_pretty(pg_relation_size(oid)) AS file_size,
       pg_size_pretty((pgstattuple(oid)).tuple_len) AS actual_data
FROM pg_class
WHERE relname IN ('demo', 'demo_pkey');

大半の行を削除

DELETE FROM demo WHERE id BETWEEN 10001 AND 90000;
VACUUM demo;

VACUUM 後のスナップショット：

• テーブルは縮小した。
• インデックスのサイズは変わらない。
• VACUUM は OS にスペースを返さず、ページを再利用可能にしかマークしない。

ページ状態

VACUUM

フィルファクター

• 挿入時にページをどれくらい埋め込むかを決定。
• デフォルトは B‑tree の fillfactor が 90 %。
• 低く設定（例：

  WITH (fillfactor = 70)

  ）すると将来の挿入余地が増えるが、ほとんど行を削除した場合には膨張が 悪化 します。

プランナーの誤推定

EXPLAIN ANALYZE SELECT * FROM demo WHERE id BETWEEN 10001 AND 90000;

プランナーは 200 行と想定したが、実際は 0 行。
インデックスに空きページが多いためです。

ANALYZE

relpages

インデックス統計

SELECT * FROM pgstatindex('demo_pkey');

注：86 % の密度は健全に見えるが、インデックスファイルの 79 % が不要である。

膨張率

SELECT c.relname AS index_name,
       pg_size_pretty(pg_relation_size(c.oid)) AS actual_size,
       pg_size_pretty((c.reltuples * 40)::bigint) AS expected_size,
       round(pg_relation_size(c.oid)/NULLIF(c.reltuples*40,0),1) AS bloat_ratio
FROM pg_class c
JOIN pg_index i ON c.oid = i.indexrelid
WHERE c.relkind = 'i'
  AND c.reltuples > 0
  AND c.relname NOT LIKE 'pg_%'
  AND pg_relation_size(c.oid) > 1_048_576;

約 2.0 を超える比率は調査のサインです。

問題解決策

REINDEX

REINDEX INDEX CONCURRENTLY demo_pkey;

再構築後：

インデックスは 2.2 MB → 456 KB（約 79 % 削減）。

Tip:

REINDEX CONCURRENTLY

は排他ロックを避けられ、PostgreSQL 12 以降で利用可能です。

pg_squeeze

• テーブルとインデックスをオンラインで再構築し、ロックを最小限に抑える。
• ロジカルディコードを使用するため、稼働中のシステムへの影響が少ない。

CREATE EXTENSION pg_squeeze;
SELECT squeeze.squeeze_table('public', 'demo');

注意：

pgstatindex()

はインデックス全体を読み込むので、大きなインデックスでは避けるべきです。

いつ対処すべきか

bloat_ratio

結論

• VACUUM はヒープの膨張は解消する が、インデックス構造はそのまま。
• インデックスの膨張には明示的な操作（REINDEX、pg_squeeze、あるいは VACUUM FULL）が必要です。

差異を理解し、適切な指標を監視して、VACUUM の静寂がすべて正常であると勘違いしないようにしましょう。