SQLが「実行計画」に辿り着くまでの静かなる闘い：クエリアナライザの深淵
PostgreSQLを触っていると、たまに「なぜこのクエリはこんなに解析に時間がかかっているんだ？」と首を傾げたくなる瞬間があるはずだ。複雑すぎる巨大なJOIN、あるいは膨大なパーティションテーブルを抱えたスキーマ。
多くの場合、チューニングの対象は「実行計画（プランナ）」に向けられがちだ。しかし、その前段に位置する「アナライザ（Analyzer/Rewriter）」というゲートキーパーが、実はシステムの安定性に大きな影響を与えていることに気づいているエンジニアはどれくらいいるだろうか。
今回は、PostgreSQLのコアアーキテクチャの中でも、SQLを「ただの文字列」から「機械が理解できる構造体」へと昇華させる、この知的なプロセスについて掘り下げてみたい。
—
1. パース後の静寂：解析ツリーからクエリツリーへ
パーサがSQLを文法的に解釈して「解析ツリー（Raw Parse Tree）」を生成した直後、バトンはアナライザに渡される。ここで行われるのは、単なる文法チェックではない。「意味論的妥当性の検証」という、極めて厳格な作業だ。
アナライザは、システムカタログ（`pg_class`, `pg_attribute`, `pg_type` など）を縦横無尽に参照する。
- 名前解決: そのテーブルは本当に存在するのか？ その列にアクセスする権限はあるか？
- 型推論: `COALESCE`の結果や、演算子のオーバーロードはどう処理されるべきか？
- スコープの定義: サブクエリ内の相関名（Alias）は正しく外側のクエリとマッピングされているか？
このプロセスを経て、曖昧だった解析ツリーは、PostgreSQLが最適化のために理解できる「クエリツリー（Query Tree）」へと変換される。ここで生成される構造体は、後のプランナがコスト計算を行うための「厳密な設計図」となるわけだ。
2. 実践的なパフォーマンストラブルシューティング：ここがボトルネックになる
「クエリアナライザが遅い」なんてことは、通常のアプリケーションではまず起きない。だが、大規模なエンタープライズ環境や、極端に複雑なスキーマ設計においては、ここが無視できないオーバーヘッドになることがある。
① カタログアクセスの競合
アナライザは、SQLを実行するたびにシステムカタログを読みに行く。もし、数千のテーブルを持つデータベースで、頻繁にクエリの解析が発生すればどうなるか。カタログに対するロック競合（`AccessShareLock`）が、実はクエリのレイテンシに悪影響を及ぼしているケースがある。
特に、`pg_attribute`などは頻繁に参照されるため、システムカタログのメモリキャッシュ（`relcache`や`catcache`）のヒット率を監視しておくことは、DBAの嗜みと言ってもいい。
② 巨大なクエリの「解析コスト」
かつて、数千行にも及ぶ複雑なCASE文や、数百個のJOINを含むSQLを見たことがあるだろうか。アナライザはこれら全てをメモリ上でクエリツリーに展開する。
解析ツリーのノード数が膨大になると、構造体の生成だけでCPU時間を浪費し、メモリ使用量も跳ね上がる。プランナに渡す前のこの段階で「解析時間」が伸びるケースは、意外と見落とされがちだ。
- 対策のヒント: `EXPLAIN`コマンドを実行した際、実行計画が出るまでにラグがある場合は、プランナではなくアナライザが苦しんでいる可能性を疑うべきだ。
3. なぜ「ビュー」や「ルール」が厄介なのか
アナライザの後に続く「リライタ（Rewriter）」の存在も忘れてはいけない。ビュー（View）やルール（Rule）が絡むと、アナライザが生成したクエリツリーは、さらに複雑に「書き換え」られる。
ビューを多重にネストさせると、システムカタログへの再帰的なアクセスが発生し、解析コストは幾何級数的に増加する。クエリのパフォーマンスが悪い時、「ビューの実行結果が遅い」のではなく、「ビューの定義を解析して最終的なクエリツリーに展開するまでのコスト」が重いというケースは珍しくない。
シンプル・イズ・ベスト。PostgreSQLの内部構造を知れば知るほど、この格言の重みが増していく。
—
最後に：エンジニアとしての視座
PostgreSQLは、クエリが投げられてから結果が返ってくるまで、驚くほど緻密なプロセスを踏んでいる。アナライザは、データベースの「知性」そのものだ。
もし、あなたが今、不可解なパフォーマンス低下に悩んでいるなら、一度`pg_stat_statements`で実行時間を眺めるだけでなく、`log_min_duration_statement`を調整して、そのクエリが「どのフェーズで」時間を食っているのかを観察してみてほしい。
内部構造を知ることは、単なる趣味ではない。それは、データベースという巨大な機械を、意のままに操るための「地図」を手に入れることなのだから。
それでは、また次回の深掘りでお会いしよう。あなたのクエリが今日も快適に走ることを願っている。
コメント