【入門編】 effective_cache_size設定 – PostgreSQL

こんにちは！データベースの世界へようこそ。
日々PostgreSQLと向き合っていると、「クエリが遅いな…」と悩む夜もありますよね。そんな時に耳にするのが『effective_cache_size』という設定値。

名前からして何やら難しそうですが、実はこれ、「データベースが、OSのキャッシュをどれくらい頼りにしていいか」をプランナ（検索の作戦を立てる人）に教えてあげるためのヒントなんです。

今日は、専門用語を抜きにして、皆さんがイメージしやすい「図書館」に例えて解説していきますね。

—

想像してみてください。あなたは巨大な図書館の司書さんです。
目の前には何百万冊もの本（データ）がありますが、すべてを机の上に広げておくことはできません。

ここで重要なのが「OSのキャッシュ」という存在です。これは、「最近よく読まれている本を、カウンターのすぐ後ろの棚に一時的に置いておく」という、図書館の便利な仕組みだと思ってください。

さて、PostgreSQLのプランナは、検索の作戦を立てるときにこんなふうに考えます。

「なるほど、このデータを探すなら、インデックス（索引）を使おうかな。でも、そのインデックスデータって、今カウンターのすぐ後ろの棚（OSキャッシュ）にあるのかな？それともわざわざ遠い書庫まで走らないといけないのかな？」

もし、OSキャッシュがパンパンに詰まっているなら、「たぶん後ろの棚にあるから、インデックスをフル活用して高速に探そう！」という強気な作戦を選べます。逆に、OSキャッシュが小さければ、「書庫まで走るのが面倒だから、別の方法で探そうかな」と慎重になります。

『effective_cache_size』は、まさに「カウンターの後ろの棚（OSキャッシュ）って、どれくらいの容量があるの？」と司書さん（プランナ）に伝える数字なんです。

もし、この設定が実態と大きくズレていたらどうなるでしょうか。

「後ろの棚はほとんど空っぽだ」と思い込ませてしまいます。するとプランナは、「インデックスを使ってもどうせ書庫に取りに行くことになるから、最初から全部の本を机に広げちゃおう（フルスキャン）」なんていう、効率の悪い作戦を選んでしまうことがあります。

「後ろの棚には何でも入っている！」と過信させてしまいます。その結果、本当は書庫に取りに行かなければならないのに、「後ろにあるはずだ」と思ってインデックスを多用し、結果として検索が遅くなってしまうのです。

初心者の方がまず押さえておきたいのは、「OSがファイルシステムキャッシュとして利用できるメモリの量」を目安にする、ということです。

一般的には、「サーバーに搭載されているメモリの半分から75%くらい」を目安に設定するのが定石と言われています。

もちろん、これはあくまで「目安」です。サーバー上で他のアプリケーションが動いていたり、DB以外の仕事が忙しかったりする場合は、もう少し控えめにするのが賢い選択かもしれません。

データベースのチューニングと聞くと、「魔法の数字を入力して爆速にする」というイメージがあるかもしれません。でも実際は、データベースという「司書さん」と、「今の状況はどう？」と対話していく作業に近いんです。

「effective_cache_size」を少し変えてみて、実際の検索速度が変わるか試してみる。そんな小さな実験を繰り返すことで、あなたのPostgreSQLはどんどん頼もしい相棒に育っていきますよ。

難しく考えすぎず、まずは今の設定値を確認するところから始めてみませんか？
何か分からないことがあれば、いつでもまた聞きに来てくださいね！応援しています。