【テクニカル・上級編】ルールシステム（CREATE RULE） – PostgreSQL

PostgreSQLの深淵を覗いていると、必ずと言っていいほど「CREATE RULE」という強力だが、どこか近寄りがたい存在にぶつかるはずだ。

マニュアルには「クエリ書き換えシステム」とある。確かにその通りだ。しかし、この機能はただの便利ツールではない。エンジニアとして長く現場に立っていると、このルールシステムが時に「魔法の杖」になり、そして時に「悪夢のトリガー」になることを嫌というほど思い知らされる。

今日は、この「ルールシステム」の内部挙動と、なぜ多くの熟練者がこれを避けたがるのか、あるいはどのような場面で真の力を発揮するのかについて、少しディープに掘り下げてみたいと思う。

—

まず理解しておかなければならないのは、ルールシステムが実行されるタイミングだ。PostgreSQLのクエリ処理パイプラインにおいて、ルールは「解析（Parsing）」の直後、つまり「プランニング（Planning）」の前に行われる。

ここが重要だ。ルールはクエリツリーを書き換える。 プランナが最適化の計算を始める前に、SQLの構造そのものを差し替えてしまうんだ。

トリガー（Trigger）との違い： 行レベルのトリガーはデータが変更される際、「実行時」に動く。一方、ルールはクエリが「コンパイル」される段階で介入する。
プランナの盲点： ルールによって挿入された複雑な条件や結合は、プランナから見ると「最初からそこに書かれていたクエリ」として扱われる。これにより、時には期待しない複雑な実行計画が生成され、インデックスが無視されたり、Nested Loopが爆発したりする。

この「プランナの最適化のスコープ外でクエリの骨格が変わってしまう」という性質こそ、ルールが「取り扱い注意」と言われる最大の理由だ。

PostgreSQLでビューを更新可能にする際、`INSTEAD` ルールを使うのが古くからの定石だ。最近では `INSTEAD OF` トリガーの方が推奨されることが多いが、あえてルールを選ぶ現場にはそれなりの理由があるはずだ。

ルールを使ったビューの更新は、クエリが「書き換え」によって透過的に行われるため、非常にクリーンに見える。しかし、トラブルシューティングの現場では、これが仇になる。

デバッグの困難さ： `EXPLAIN` を叩いても、見えるのは「書き換え後の姿」だけだ。元のSQLと、実行されている実体の乖離を脳内で補正し続けなければならない。
多重書き換えの罠： 複数のルールが重なると、クエリツリーは指数関数的に膨れ上がることがある。特にサブクエリを含んだ更新ルールは、プランナにとって悪夢のような複雑さを生む。

もし、ビューの更新にルールを使っているなら、時折 `EXPLAIN` だけでなく `EXPLAIN (VERBOSE)` を使って、実際にどのテーブルに対してクエリが投げられているのかを再確認することをお勧めする。

ここまで脅すようなことばかり書いたが、ルールシステムは決して「排除すべき悪」ではない。適切に使えば、他のどの機能よりも洗練された解決策になる。

例えば、「パーティショニングの古典的な実装」や、「特定のクエリを強制的に別テーブルへリダイレクトする」といったメタな処理において、ルールは唯一無二の性能を発揮する。

ルールを使いこなすための判断基準はシンプルだ。

1. 「その処理はデータの内容に依存しているか？」（それならトリガーだ）
2. 「その処理はクエリの構造そのものを変更すべきか？」（それならルールだ）

もしルールを採用するなら、徹底的にテストすること。特に、想定される結合条件において、プランナがインデックスを正しく選択できているか。統計情報がルールによって挿入された述語に対してどう反応しているか。

PostgreSQLのルールシステムは、いわば「外科手術用のメス」だ。切れるときは恐ろしく美しく切れるが、扱いを誤れば患者（データベース）に深刻なダメージを与える。

現代のPostgreSQLには、より安全で汎用的な代替手段が増えた。しかし、この「クエリを書き換える」という原始的で強力なレイヤーを理解しておくことは、大規模なシステムで予期せぬパフォーマンス劣化に遭遇した際、必ず大きな武器になる。

データベースの内部で何が起きているか。SQLというテキストの背後にある「木構造」を想像する癖をつけること。それが、真のデータベースエンジニアへの道だと、私は信じている。

さて、今日はこの辺で。また深淵を覗く機会があれば、続きを語ろう。