「なぜか遅い」を解決する魔法の数字？ PostgreSQLの`cpu_tuple_cost`を優しく解説
こんにちは！データベースの世界にどっぷり浸かって十数年、今日も今日とてSQLの海を泳いでいるエンジニアです。
皆さんはPostgreSQLを使っていて、「どうしてこのクエリ、こんなに時間がかかるんだろう？」と首をかしげたことはありませんか？実はその原因、データベース君が「仕事の見積もり」を間違えているからかもしれません。
今日は、そんな見積もりミスを解消するちょっとマニアックだけど頼もしい設定値、`cpu_tuple_cost`についてお話ししますね。
—
「仕事の見積もり」ってどういうこと？
まず、データベースがクエリを処理する時のことを想像してみてください。
あなたが本棚から特定の資料を探すとき、「本棚を上から順に全部チェックする」のと「索引を使ってパッと目的のページを開く」のとでは、どちらが早いかすぐ分かりますよね。
PostgreSQLも同じで、クエリが来ると「どの方法でデータを集めるのが一番早いかな？」と脳内でシミュレーションを行います。この「シミュレーション（計画作成）」の際に使われるのが、各操作にかかる「コスト（重さ）」の計算です。
`cpu_tuple_cost` は「一行あたりの重さ」
ここで登場するのが、今回の主役 `cpu_tuple_cost` です。
これは、簡単に言うと「テーブルから一行（タプル）を取り出して、中身をチェックするのにかかるCPUコスト」のこと。
例えるなら、「段ボール箱から書類を一枚取り出して、中身を確認するのにかかる時間」です。
- 箱が10個なら、大した手間ではありませんよね。
- でも、箱が100万個あったらどうでしょう？「一枚確認するのに0.1秒かかる」という前提が少しでもズレていたら、100万回繰り返した時の合計時間はとんでもないことになります。
PostgreSQLのデフォルト設定は、いわば「一般的なオフィスでの作業スピード」を想定しています。でも、皆さんが使っているサーバーのCPUが爆速だったり、逆に特殊な計算が必要な環境だったりすると、この「0.1秒」という前提が現実と噛み合わなくなってしまうんです。
なぜ調整が必要なの？
もしデフォルトのコスト見積もりが「実際の作業スピード」よりも重く設定されていたら、データベース君はこう考えます。
「一行ずつチェックするのは時間がかかりすぎる！ よし、別の方法（索引をフル活用するような、ちょっと複雑な方法）をとろう！」
結果、本当は一行ずつチェックしたほうが速いのに、わざわざ遠回りをしてしまうという悲劇が起こります。逆に、甘く見積もりすぎると、無理な検索をして結局時間がかかることも。
この「見積もり」と「現実」のギャップを埋めるのが、このパラメータの役割なんです。
調整のヒント：まずは観察から
「じゃあ、すぐに数値をいじってみよう！」……と意気込みたいところですが、ちょっと待ってくださいね。
この設定は、データベース全体に影響を与える「劇薬」のようなものです。闇雲にいじる前に、まずは以下のステップを大切にしてみてください。
1. `EXPLAIN ANALYZE` を使ってみる
クエリの先頭にこれを付けるだけで、PostgreSQLが「どうやってそのデータを取ってきたか」を教えてくれます。「あれ、本当は100行くらいで済むはずなのに、何万行もスキャンしてる？」といった違和感に気づくことが第一歩です。
2. まずは「統計情報」を疑う
`cpu_tuple_cost`をいじる前に、データが最新の状態になっているか（`ANALYZE`コマンド）を確認してください。たいていの場合、見積もりが狂っているのは数値のせいではなく、データベースが「中身が古い」と思い込んでいるからです。
3. 本当に必要なら慎重に
それでも「どうしてもこのクエリだけ重い」という場合、そのクエリだけの設定を変更したり、あるいは全体の設定を少しずつ調整してみたりしましょう。
—
最後に：データベースとの対話を楽しもう
`cpu_tuple_cost`のような設定値は、データベースという巨大な機械を動かすための「チューニングのスパイス」のようなものです。
最初は難しく感じるかもしれませんが、「データベース君は今、どんなふうに頑張ろうとしているのかな？」と想像できるようになると、途端に愛着が湧いてきますよ。
まずは怖がらずに `EXPLAIN` の結果を眺めるところから始めてみてください。あなたのクエリが、昨日よりも少しだけ軽快に動くようになりますように！
それでは、また次回のブログでお会いしましょう。ハッピー・クエリライフ！
コメント