1冊目を間違えると障害の切り分けに使えない
この記事は要約版です。省略した詳しい解説や手順は、ブログの完全版にまとめています: PostgreSQL本おすすめ｜レベル別の読む順番
PostgreSQL関連の書籍を検索すると、SQL入門書と内部構造の解説書、試験対策本が同じ一覧に並びます。ところが「テーブル設計を任された」「VACUUMが追いつかずテーブルが肥大化した」「実行計画が読めない」は、それぞれ別の層の課題です。層が合っていない本を1冊目に選ぶと、読み終えても目の前の障害を切り分けられません。
書籍は3層に分かれ、層をまたいだ比較はできない
第1層はSQLとリレーショナルモデルです。JOIN、集約、ウィンドウ関数、CTE、正規化と制約設計を扱い、MySQLやOracleでもほぼそのまま通用します。
第2層が内部構造とアーキテクチャです。MVCCのxmin/xmaxと可視性判定、WALとチェックポイント、VACUUMとFREEZE、共有バッファ、プランナの推定、ロック競合を扱います。「なぜUPDATEだけでテーブルが太るのか」「なぜインデックスがあるのにSeq Scanになるのか」に答えられるのは、この層の知識だけです。
第3層は運用・チューニング・トラブルシュートです。postgresql.confのパラメータ設計、バックアップとPITR、監視項目、スロークエリの特定が中心になります。第2層が抜けた状態で第3層の本を読むと、設定値の暗記リストにしか見えません。実務で止まる人の多くは、第1層だけを固めた状態で第3層の作業を任されています。
選ぶ軸は対象レイヤ・前提知識・対応バージョン・ハンズオン量
目次に「JOIN」「ウィンドウ関数」が並ぶならSQL層、「MVCC」「WAL」「VACUUM」が章になっていれば内部構造層、「パラメータ」「バックアップ」「監視」が並べば運用層と判断できます。前提知識はpsqlの操作説明があるかどうかで見分けてください。
対応バージョンの扱いは層によって変わります。SQL構文とリレーショナルモデルの本は、古い版でも大半が通用します。一方でautovacuumのトリガ条件、インデックスの内部最適化、バックアップ手順はバージョン差が実務に直結します。PostgreSQL 12でrecovery.confが廃止され、リカバリ設定がpostgresql.confとstandby.signal/recovery.signalへ統合された変更は、手順書レベルで影響します。第2層と第3層は新しい版を選び、差分はリリースノートと公式ドキュメントで埋めるのが現実的です。
3か月で一周する順番
週5〜8時間を確保できる前提なら、1〜4週でSQLとリレーショナルモデル、5〜8週でMVCC・WAL・VACUUM、9〜12週で実行計画とバックアップ運用という配分になります。到達判定は読了ではなく、自分の言葉で説明できるかどうかで行ってください。たとえばLEFT JOINの結果に右表の条件をWHEREへ書くと内部結合相当になる理由、HOT updateが効く条件、VACUUM FULLを本番で避ける理由を説明できるかが目安です。
読みながら手元で確かめる
MVCCの章を読んだら、可視性とデッドタプルを自分で観察します。
CREATE TABLE t (id int primary key, v text);
INSERT INTO t VALUES (1, 'a');
SELECT ctid, xmin, xmax, * FROM t;
UPDATE t SET v = 'b' WHERE id = 1;
-- 更新後、新しいタプルの位置（ctid）が変わっていることを確認
SELECT ctid, xmin, xmax, * FROM t;
-- デッドタプルの状況
SELECT relname, n_live_tup, n_dead_tup, last_autovacuum
FROM pg_stat_user_tables WHERE relname = 't';
実行計画は推定値だけでは判断できません。実測と比較するため、ANALYZEとBUFFERSを付けて取得します。
EXPLAIN (ANALYZE, BUFFERS, VERBOSE)
SELECT o.id, c.name
FROM orders o
JOIN customers c ON c.id = o.customer_id
WHERE o.created_at >= now() - interval '7 days';
内側のノードから外へ読み、rows=の推定とactual rows=の実測が10倍以上ずれていないか、Buffers のreadが多くないか、Sort Method に external merge Disk が出ていないかを確認します。章を読み終えるたびに、その主張が成り立たない条件を作って試すと定着します。autovacuum = off にして大量UPDATEを繰り返し、n_dead_tupとテーブルサイズの増え方を見るのが分かりやすい例です。
OSS-DB Silverとの使い分け
期限付きで合格が必要なら対策本と問題集を先に回し、期限がなく実務で使えるようになりたいなら技術書を先に読みます。迷う場合は業務での接触頻度で決めてください。週に数回以上触っているなら技術書優先、ほとんど触っていないなら対策本優先です。なお試験のバージョンと出題範囲は改訂されるため、申し込み前に公式サイトで最新の範囲を確認してください。
1冊目に迷ったら第2層を選ぶと後が楽になります。MVCC・WAL・VACUUM・プランナの4つを理解しておけば、第1層のSQLの良し悪しも第3層のパラメータ設計の意味も、後から自分で判断できます。
詳しくは
元記事では、層ごとの選定基準を目次レベルまで分解し、ウィンドウ関数やpageinspectの有無といった具体的な見分け方を挙げています。あわせて12週ロードマップの到達チェック項目、pg_stat_statementsやpg_stat_activity、pg_locksを使った症状別の調査順、バージョンを並べて比較できるDocker Composeの検証環境、MySQLやOracle経験者が意識すべき実装差も扱っています。