PostgreSQL の本領は『計画的に速くする』
PostgreSQL は機能の幅広さと信頼性で広く採用される RDBMS です。本記事では編集部の視点で、実務で押さえるべき高速化と設計の要点を公開情報をもとに整理します。REST API設計 もご参考に。
インデックスの基本
(1) B-tree：等価/範囲検索の万能型。(2) 複合インデックス：左から使われる原則。(3) カバリングインデックス：INCLUDE で SELECT 列を含める。(4) 部分インデックス：WHERE 句で限定し小さく。(5) 未使用インデックスは削除：書込性能を犠牲にしない。
特殊インデックスの活用
(1) GIN：JSONB / 全文検索に最適。(2) GIST：地理情報 / 範囲型。(3) BRIN：巨大テーブルの順序データを軽量に。(4) Hash：等価検索のみ。最近改善された。(5) SP-GIST：空間データ向け。
EXPLAIN の読み方
(1) EXPLAIN ANALYZE：実測のコストと行数。(2) Seq Scan：全表スキャン。大きな表では危険信号。(3) Index Scan / Bitmap Index Scan：インデックス利用。(4) Hash Join / Merge Join / Nested Loop：結合戦略。(5) actual time vs cost：見積もりとの乖離が大きいと統計情報の更新が必要。Observability 実践 でクエリログ可視化。
パーティショニング
(1) RANGE：日付/IDの範囲で分割。(2) LIST：地域/カテゴリ等の離散値。(3) HASH：分布の均等化。(4) パーティション pruning：不要なパーティションをスキップ。(5) 10GBを超えたら検討が目安(公開情報をもとに)。
運用で気をつけること
(1) autovacuum チューニング：書き換え多いテーブルは個別調整。(2) connection pool：PgBouncer 推奨。(3) レプリケーション：物理(streaming) と 論理(pub/sub) を使い分け。(4) WAL とバックアップ：pg_basebackup + 連続WALで PITR。(5) 監視：long_query / blocking / replication lag を重点監視。k8s 本番運用 でステートフル運用の参考に。
失敗しがちなパターン
(1) インデックスを貼りすぎ：INSERT が遅くなる。(2) autovacuum 無効化：膨張で全停止。(3) SELECT * の常用：転送コストが累積。(4) JSONB の乱用：型安全性とパフォーマンスを失う。(5) 接続数の上限超過：プールなしで爆発。対策は、(1)使用率分析→棚卸し、(2)autovacuum微調整、(3)必要列のみ、(4)正規化と JSONB の使い分け、(5)PgBouncer 必須、です。