「PostgreSQLのプランナ設定」を料理に例えて攻略しよう！
みなさん、こんにちは！データベースの世界へようこそ。
PostgreSQLを使っていると、「どうしてこのクエリ、こんなに遅いの？」と頭を抱える夜がありますよね。そんな時、ベテランエンジニアたちがコソッと触るのが「プランナ制御パラメータ」という設定です。
名前だけ聞くと難しそうですが、実はこれ、料理の「調理法選び」に例えるとものすごく分かりやすいんです。今日は、その魔法のスイッチについてお話ししますね。
—
「プランナ」は優秀なシェフ
まず、PostgreSQLの「プランナ」という存在を、厨房にいる凄腕のシェフだと想像してみてください。
あなたが「このデータ全部ちょうだい！」と注文すると、シェフは「よし、それなら一番早い方法で用意しよう！」と、頭の中でレシピ（実行計画）を組み立てます。
- 「冷蔵庫の全食材を端から端までチェックするか（全件検索）」
- 「メモ帳（インデックス）を見て、必要な食材だけピンポイントで取るか（インデックス検索）」
基本的には、このシェフは非常に優秀です。でも、たまに「いやいや、今はそんなやり方より、こっちの方が絶対早いって！」と、人間がツッコミを入れたくなる時があるんですよね。
そんな時に使うのが、今回紹介する設定パラメータです。
—
「enable_」でシェフの選択肢を制限してみる
PostgreSQLの設定ファイルには、`enable_seqscan` や `enable_indexscan` といった項目が並んでいます。これらは、シェフに対して「この調理法は使っちゃダメ！」と指示する命令書のようなものです。
例えば、こんな感じです。
- enable_seqscan = off
「全部片っ端から探す（全件スキャン）のは禁止！」
→ お店にある食材を一つずつ確認するのは時間がかかるから、絶対にインデックスを使って探しなさい、という指示です。
- enable_indexscan = off
「インデックス（索引）を使うのは禁止！」
→ あえて遠回りしてでも、全てのデータを確認させたい特殊な状況で使います。
- enable_hashjoin = off
「ハッシュジョイン（食材を一度広げて合わせる手法）は禁止！」
→ データを一度メモリに広げる方法がうまくいかない時に、別の方法を選ばせることができます。
—
注意！「禁止」はあくまで最終手段
ここで一つ、僕からすごく大切なアドバイスがあります。
「enable_系」のパラメータは、基本的には触らないのが一番です。
これらをオフにすると、シェフは「あ、これ使っちゃダメなんだね」と、無理やり別の調理法を選びます。でも、それが必ずしも「最適」とは限りません。シェフが「あえて」その手法を選んでいたのには、データベースの統計情報に基づいた深い理由があることがほとんどだからです。
まるで、「包丁は危ないから禁止！」とシェフに伝えたら、スプーンで野菜を切り始めた……みたいな悲劇が起きることもあります。
こんな時にだけ使ってみて
もしこれらのパラメータを触るなら、それは「このクエリがなぜ遅いのか」を検証する時だけにしてください。
「このインデックスを使えば速くなるはずなのに、なぜかプランナが選んでくれない……」という謎解きをする際、一時的に他の手法をオフにして、強制的にそのインデックスを使わせてみる。そうすることで、「インデックスを使った方が実は遅いのか、それともプランナがデータの量を勘違いしているのか」という原因が見えてくるんです。
—
まとめ：シェフを信じつつ、たまにヒントを
データベースチューニングの醍醐味は、プランナと対話することにあります。
いきなり設定をいじって「禁止」を連発するのではなく、まずは「どうしてこのプランを選んだのかな？」と、シェフ（プランナ）の視点に立って考えてみてください。
もしどうしても調整が必要なら、パラメータを制限するのではなく、「統計情報を更新する（ANALYZE）」とか「インデックスを見直す」といった、もっと根本的なケアをしてあげるのが、実は一番の近道だったりします。
みなさんのデータベースが、今日もサクサク元気に動きますように。また次回の記事でお会いしましょう！
コメント