PostgreSQLの「禁じ手」？プランナメソッド設定と上手く付き合う技術
やあ。今日はちょっと「現場の裏技」というか、PostgreSQLのクエリチューニングにおける諸刃の剣、「プランナメソッド設定（enable_xxx）」の話をしようと思う。
PostgreSQLのオプティマイザは非常に優秀だ。基本的には、統計情報をもとに「一番速い実行計画」を自分で導き出してくれる。でも、稀に……そう、本当に稀にだけど、「いや、お前絶対そっちのインデックス使った方が速いだろ！」と、プランナに文句を言いたくなる瞬間があるよね。
そんな時、つい手を伸ばしたくなるのが `enable_seqscan` や `enable_indexscan` といった設定パラメータだ。今日はこれらをどう扱うべきか、現場の視点で語らせてほしい。
—
そもそも「プランナメソッド設定」って何？
PostgreSQLには、実行計画を決定する際に「どの手法（スキャンや結合の方法）を検討対象にするか」を制御するためのパラメータ群がある。
例えば、こんな感じだ。
— シーケンシャルスキャンを禁止する（自己責任で！）
SET enable_seqscan = off;
— クエリ実行…
— 元に戻すのを忘れずに
SET enable_seqscan = on;
これを使うと、強制的にシーケンシャルスキャン（全件走査）を禁止できる。一見、最強のチューニングツールに見えるよね。特定のクエリだけが「なぜかインデックスを使わず、全件走査して遅延している」ような状況で、無理やりインデックスを強制できるからだ。
—
現場の先輩からの忠告：これは「治療」ではなく「鎮痛剤」だ
まず、大前提を伝えておくよ。これらは本番環境の恒久的な解決策として使うものじゃない。
もし君が「遅いから」という理由で、安易に `enable_seqscan = off` を本番のセッション設定に書き込もうとしているなら、一度手を止めてほしい。なぜなら：
1. 環境の変化に弱くなる: 統計情報が変わった時、以前は最適だった計画が、設定を縛ったせいで最悪な計画に化けることがある。
2. メンテナンス性が最悪: 数ヶ月後、君が異動したあとに別のエンジニアがこのコードを見たらどう思うか？「なんでこんな設定が？」と頭を抱えることになるのは想像に難くないはずだ。
3. 副作用の嵐: 全件走査を禁止した結果、インデックスの「範囲スキャン（Index Range Scan）」が多発して、結局フルスキャンより遅くなる……なんていうのはよくある悲劇だ。
—
どうしても使いたい時の「作法」
とはいえ、デバッグ中や、どうしてもオプティマイザが間違った判断をしている時の「切り分け」にはめちゃくちゃ役に立つ。
例えば、クエリがなぜ遅いのかを探るために、「あえて」インデックスを使わせない実行計画と比較して、コストの差を確認する。これはプロの調査手法だ。
おすすめの使い分けフロー
1. まずは `EXPLAIN ANALYZE` を見る: オプティマイザが「なぜその計画を選んだのか」を考える。大抵は統計情報の古さや、相関関係の欠如が原因だ。
2. `ANALYZE` を叩く: これだけで直るケースが実は8割。
3. 統計情報の精度を上げる: `ALTER TABLE … SET STATISTICS` で、該当カラムのヒストグラムの精度を上げてみる。
4. それでもダメなら（検証用として）`enable_xxx` を使う: 「このインデックスを使えば速くなるはずだ」という仮説を検証するために一時的に設定をいじる。
5. 解決策を適用する: 「このインデックスが使われないのは、このカラムのデータ分布が特殊だからだ」と分かったら、設定をいじるのではなく、インデックスの定義を見直すか、クエリの書き方を工夫してオプティマイザを誘導する。
—
最後に：賢いエンジニアのたしなみ
PostgreSQLは、君が設定をいじらなくても、正しくインデックスを貼り、正しく統計情報を更新していれば、ほとんどのケースで最適な回答をくれる。
`enable_seqscan = off` を使うのは、医者が「鎮痛剤」を処方するのと同じだ。痛みは一時的に消えるけれど、根本的な「病気（統計の不備やクエリの構造的問題）」を治したことにはならない。
もし君が現場で「このクエリ、どうしてもインデックスを使ってくれないんです……」と悩んだら、まずはこのパラメータで遊んでみていい。ただし、「なぜオプティマイザがその計画を選んだのか？」という問いに対して、自分なりの答えを見つけることだけは忘れないでほしい。
それが、ただの「設定いじり屋」ではなく、世界最高峰のデータベースエンジニアへの一歩だからね。
それじゃ、また現場で会おう。良いチューニングを！
コメント