【入門編】 クエリプランナのコストモデル – PostgreSQL

こんにちは!データベースの世界へようこそ。

今日は、PostgreSQLの「クエリプランナ」という、ちょっと頭のいい執事さんの話をしてみたいと思います。

皆さんは、本屋さんで分厚い専門書を探すとき、どうやって探しますか?端から順番に一冊ずつ背表紙を眺めていくでしょうか。それとも、店員さんに「あのタイトルの本はどこ?」と聞いて、特定の棚まで一直線に向かうでしょうか。

実は、PostgreSQLもこれと全く同じことをしています。私たちが「このデータが欲しい!」と命令したとき、PostgreSQLの中の「プランナ(計画係)」という担当者が、「どうやって探すのが一番早いかな?」と一生懸命シミュレーションをしているんです。

今日は、そのプランナが何を基準に「こっちの道の方が速い!」と判断しているのか、その裏側の秘密を覗いてみましょう。

プランナの頭の中にある「コスト計算」

PostgreSQLのプランナは、とてつもなく現実的です。「速さ」を測るために、ある計算式を使っています。それが「コスト」という概念です。

このコストを計算するために、PostgreSQLにはいくつかの設定値があります。専門用語っぽくて難しそうに見えますが、日常生活に置き換えるとすごくシンプルなんです。

1. `seq_page_cost`(順番に読むコスト)

これは、本棚を端から端まで「順番に」見ていく時の手間賃です。
本が綺麗に並んでいるなら、指でなぞるだけでいいですよね。でも、1冊ずつ確認する時間はどうしてもかかります。この「1冊確認するのにかかる労力」がこれです。

2. `random_page_cost`(バラバラに読むコスト)

これが面白いところです。本棚のあちこちにある本を、飛び石のように拾い読みする時のコストです。
想像してみてください。あっちの棚へ行き、次は反対側の棚へ走り、また戻ってくる……。これって、順番に読むよりずっと疲れますよね? PostgreSQLにとっても、ディスクのあちこちへデータを拾いに行くのは、順番に読み進めるよりもずっと「重労働」なんです。

なぜこの設定が大切なの?

「そんなの、全部コンピューターにお任せでいいんじゃないの?」と思いますよね。でも、ここがエンジニアの腕の見せ所なんです。

例えば、皆さんの使っているパソコンが、昔ながらの「HDD(ハードディスク)」なのか、それとも爆速の「SSD」なのかで話が変わってきます。

  • HDDの場合: 物理的にディスクを回転させてヘッドを動かすので、あちこち飛び回る(ランダムアクセス)のはすごく時間がかかります。だから、`random_page_cost`は高めに設定しておかないと、プランナは「あ、あっちのデータもこっちのデータもバラバラに拾ってくればいいや!」なんて無茶な計画を立てて、動作が重くなってしまいます。
  • SSDの場合: 物理的な回転がないので、あちこち拾い読みしてもあんまり苦になりません。だから、この値を小さくしてあげると、「じゃあ、インデックスを使ってあちこち探す方法でいこう!」と、より賢い判断をしてくれるようになるんです。

調整のコツ:魔法の杖は振りすぎないで

初心者のうちは、「よし、一番速く動く設定値を教えて!」と思うかもしれません。でも、実はこのパラメータ、「絶対にこれが正解!」という数字はないんです。

大切なのは、自分の使っているデータベースが「どんな環境で動いているか」を意識すること。

もし、データベースがなんだか最近遅いな……と感じたら、まずは「今のハードウェアは、読み込みが得意な子かな?」と想像してみてください。やみくもにいじるのではなく、「ディスクが頑張りすぎていないかな?」という視点を持つだけで、皆さんのデータベースはもっと快適に動いてくれるはずです。

最後に

データベースのチューニングと聞くと、なんだか黒い画面にコマンドを打ち込む怖い作業のように感じるかもしれません。でも、やってることは「本を効率よく探すための工夫」と同じなんです。

プランナという執事さんに、「うちはこういう環境だよ、だからこっちの道の方がラクだよ」と優しく教えてあげる。そんな感覚で、少しずつ設定をいじってみてください。

もし興味が湧いたら、ぜひ `EXPLAIN` コマンドで、プランナさんがどんな計画を立てているのか眺めてみてくださいね。きっと、彼らの頑張りが見えてきて、愛着が湧いてくるはずですよ!

それでは、また次回の記事でお会いしましょう。ハッピー・クエリライフを!

コメント

タイトルとURLをコピーしました