【入門編】 work_memの最適化 – PostgreSQL

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

現場でバリバリとクエリを書いていると、たまに「あれ？さっきまでサクサク動いてたのに、急に重くなったぞ？」なんて経験、ありますよね。実はその原因、データベースの「作業机」が散らかっているせいかもしれません。

今日は、PostgreSQLのパフォーマンスを左右する縁の下の力持ち、`work_mem` について、初心者の方にも分かりやすくお話ししますね。

—

皆さんがデスクで仕事をしているところを想像してみてください。

目の前に広々としたデスクがあれば、資料を全部広げて、ハサミやのりを使って効率よく作業できますよね。でも、もしそのデスクが「ノート一冊分」くらいの小さなメモ帳サイズだったらどうでしょう？

資料を広げきれないから、一度引き出し（ディスク）にしまって、また取り出して……という作業を繰り返さないといけません。これ、めちゃくちゃ時間がかかりますよね。

PostgreSQLにおける `work_mem` は、まさにこの「作業机の広さ」のことなんです。

`work_mem` が十分にあるとき： メモリという広いデスクの上で、データの並べ替え（ソート）や、複数の情報を組み合わせる作業（ハッシュ結合）を一気に終わらせられます。
`work_mem` が足りないとき： デスクに乗り切らないデータを、一度ハードディスクという「引き出し」に逃がします。これを「一時ファイル（Temporary File）」と呼ぶのですが、この読み書きが始まると、データベースは途端に重くなってしまうんです。

—

そう思いますよね。でも、ここが難しいところなんです。

もし、全員に巨大なデスクを買い与えてしまったらどうなるでしょうか？オフィス（サーバーのメモリ）はすぐにパンクして、他の仕事ができなくなってしまいますよね。

PostgreSQLの `work_mem` は、「クエリ一つひとつ」に対して割り当てられるメモリです。もし `work_mem` を大きくしすぎて、同時に100人が複雑な検索を始めたら……。あっという間にサーバーがダウンしてしまいます。

だからこそ、この設定には「バランス感覚」が求められるんです。

—

初心者のうちは、まずはこの3つのポイントを覚えておくと安心です。

まずは、どのクエリが原因で一時ファイルができているかを確認しましょう。PostgreSQLには、実行したクエリがどれくらいディスクに書き出したかを記録する機能があります。これを見て、「あ、ここでつまづいてるな」とアタリをつけるのが第一歩です。

ここがプロの技なのですが、実は `work_mem` はデータベース全体の設定だけでなく、「今から実行するこのクエリだけ、デスクを広く使っていいよ！」と個別に指定することができるんです。

— このクエリだけ、作業机をちょっと広げてみる
SET work_mem = ’64MB’;
SELECT FROM huge_table ORDER BY created_at;

こうすれば、サーバー全体のメモリを圧迫せずに、重たい処理だけを高速化できます。賢いですよね。

いきなり数値をいじるのは禁物です。「今の設定だと、どのくらい一時ファイルができているんだろう？」というログを眺めるところから始めてみてください。案外、少しの設定変更で劇的に速くなることもありますよ。

—

データベースのチューニングと聞くと、「なんだか難しそう」と身構えてしまうかもしれません。でも、こうして「作業机」に例えてみると、少し身近に感じられませんか？

最適化の旅は、まさにデスクの片付けと一緒です。いきなり完璧を目指さず、まずは「どのクエリが、どのくらいデスクを使っているのか」を覗いてみる。そんな小さな一歩から、ぜひ楽しんでみてくださいね。

皆さんのクエリが、今日よりも少しだけ軽やかになりますように！それでは、また次回の記事でお会いしましょう。