こんにちは！データベースの世界へようこそ。
普段、私たちが何気なく「SELECT FROM users WHERE id = 1」なんてコマンドを打っていますが、PostgreSQLの中では、実はものすごいドラマが繰り広げられていることをご存知でしょうか？
今日は、クエリがデータベースに投げられてから、実際にデータを探しに行くまでの「準備運動」、その中でも特に重要な「クエリ書き換え（Query Rewriting）」というプロセスについてお話しします。
専門用語を並べるのは一旦置いておいて、ちょっとした例え話でイメージを膨らませてみましょう。
—
あなたの注文を「一番効率的な形」に翻訳するシェフ
想像してみてください。あなたは、とってもメニューが豊富な高級レストランにいます。
あなたが「いつものやつ、ちょっと特別版で！」とウェイター（パーサ）に伝えたとします。ウェイターはあなたの注文をメモしてキッチンへ運びます。でも、キッチンにいるシェフ（クエリ書き換えエンジン）は、そのメモをそのまま調理するわけではありません。
シェフは、お店の「秘伝のルール」を熟知しています。
- 「この料理には、実はこの食材を入れた方がもっと美味しくなるよね」
- 「この注文は、実はセットメニューのあっちを頼んだ方がお得じゃない？」
- 「この裏メニューは、実体はこういう材料の組み合わせなんだ」
シェフは、あなたの曖昧な注文を、厨房で一番手際よく、かつ最高に美味しく作れるレシピ（最適化されたクエリツリー）に書き換えてから調理を始めるんです。
データベースの世界での「クエリ書き換え」も、これと全く同じことをしています。
—
なぜ「書き換え」が必要なの？
PostgreSQLがクエリを受け取った直後の状態は、まだ「注文書をそのまま翻訳しただけ」の少し野暮ったい状態です。これをそのまま実行しようとすると、無駄な手間がかかったり、計算が複雑になったりしてしまいます。
そこで、クエリ書き換えエンジンが活躍します。主な役割はこんな感じです。
- 「ビュー」という名の「代理人」を呼び出す
複雑なクエリを何度も書かなくて済むように、「ビュー（View）」という仕組みを使うことがありますよね。書き換えエンジンは、「あ、これはビューの名前だな」と気づくと、その裏側にある本来のデータ構造にサッと置き換えてくれます。まるで代理人を本物に差し替えるような作業です。
- 「ルール」による自動調整
データベースには「こうなったら、こうしてね」というルールを設定できるのですが、書き換えエンジンはこれを監視しています。あなたが「データを削除する」と命令しても、裏で「削除する代わりに、削除フラグを立てる」というルールがあれば、注文内容をこっそり書き換えて、意図した通りの結果が出るように調整してくれます。
—
なぜこのステップが大切なのか
実は、この「クエリ書き換え」が終わらないと、PostgreSQLの頭脳とも言える「プランナ（実行計画作成器）」は動き出せません。
プランナは、いわば「最短ルートを見つける天才」です。「どの道を通れば一番早くデータに辿り着けるか？」を計算するのですが、書き換えエンジンがぐちゃぐちゃな注文を整理して、シンプルで美しいレシピを渡してあげないと、プランナも正しい判断ができないんです。
つまり、書き換えエンジンが優秀であればあるほど、後のデータベースの仕事が楽になり、結果として皆さんのアプリのレスポンスが爆速になるというわけですね。
—
まとめ：データベースは「あなたの意図」を汲み取っている
PostgreSQLは、ただ命令を実行するだけの冷たい機械ではありません。あなたが書いた短いコードの裏側で、データベースは「どうすれば一番効率よく、かつ安全にあなたの願いを叶えられるか？」を、この書き換えエンジンを使って常に考え続けています。
こうやって考えると、データベースと向き合うのが少しだけ楽しくなりませんか？
もし次にクエリを書くときは、「今、シェフが私の注文を最高に美味しくなるように翻訳してくれているんだな」と、心の中で少しだけ応援してあげてくださいね。
それでは、また次回の記事でお会いしましょう！Happy Querying!
コメント