PostgreSQL
実行計画の読み方遅いクエリの原因を、見積もりのずれから探す

重みは、5 つしかありません。

基準は seq_page_cost = 1.0、つまりページを 1 枚、順番に読む手間です。他のすべては、その何倍かで表されます。コストが秒ではないというのは、この意味です。

ページの重みは、行の重みの 100 倍以上です。コストの大小を決めるのは、ほとんどの場合、何行を処理するかではなく何ページ読むかです。

Seq Scan を、検算してみます。

1 万ページ・100 万行の表を、条件 1 つで絞り込む場合です。

実行計画には cost=0.00..22500.00 と現れます。条件を 2 つに増やせば最後の項が 2 倍になり、25,000 です。

絞り込んだ結果が 1 行でも、この値は変わりません。条件は全行に対して評価されるからです。Rows Removed by Filter が大きいクエリが遅いのは、まさにこの部分を払っているためです。

2 つの数字は、最初の 1 行と、最後の 1 行。

cost=0.29..22500.00 の左は最初の 1 行を返せるまで、右はすべて返し終わるまでの見積もりです。Seq Scan や Index Scan は読んだ順に返せるので、左はほぼ 0 になります。

一方、Sort やハッシュ表の構築は、入力を最後まで読み切らないと 1 行も返せません。こうしたノードでは、コストのほぼ全部が左側に乗ります。実行計画で cost=18452.11..18702.11 のように左右が近い値になっていたら、そのノードは先に全部読むタイプだと判断できます。

この区別が効いてくるのが LIMIT です。10 行だけ必要なら、プランナーは「最初の 1 行までのコスト＋残りを 10 行分だけ按分した額」で候補を比べます。左側の大きい計画はここで不利になり、Sort より Index Scan が選ばれやすくなります。LIMIT を付けた途端に計画が変わるのは、これが理由です。

インデックスのコストは、相関で動きます。

Index Scan の手間は、インデックスをたどる分と、該当行が載っている表のページを読む分に分かれます。後者が、相関によって大きく変わります。

相関が 1.0 なら、必要な行は表の中で連続して並んでいます。触るページは少なく、しかも前から順に読めるため、seq_page_cost に近い重みで数えられます。相関が 0 なら、行はばらばらの位置にあり、ほぼ行数と同じ枚数のページを random_page_cost で読むことになります。

プランナーは、この 2 つの端の値を相関の 2 乗で補間します。相関 0.5 は真ん中ではなく、ランダム側に寄った見積もりになります。相関 0.9 でようやく 8 割方が連続読み扱いです。

相関は、設定ではなく観測値です。pg_stats の correlation 列に、列ごとの値が入っています。追記中心の表の created_at は 1.0 に近く、更新の多い列では時間とともに下がります。CLUSTER で並べ替えれば上がりますが、その後の更新でまた崩れていきます。

2 度目に読むページは、割り引かれます。

Nested Loop の内側のように、同じインデックスを何度もたどる場合、2 回目以降はすでにキャッシュへ載っている可能性が高くなります。プランナーは effective_cache_size を手掛かりに、繰り返しのうち何割がキャッシュから読めるかを推定し、その分コストを割り引きます。

この設定はメモリを確保しません。「OS のキャッシュも含めれば、これくらいは載るはずだ」とプランナーへ伝えるだけの数字です。実際より小さく設定していると、繰り返しの割引が効かずインデックスが不利に見積もられ、Seq Scan が選ばれやすくなります。

Bitmap Scan は、その中間にあります。

Bitmap Index Scan は、条件に合う行が載っているページ番号だけを先に集めます。続く Bitmap Heap Scan は、その一覧をページ番号の順に読むため、同じページを何度も読み直さずに済みます。コストも、順読みとランダム読みの中間の重みで数えられます。選択率が中くらいのときにこの方式が選ばれるのは、そのためです。

実行計画の Heap Blocks: exact=... は行の位置まで記録できたページ、lossy=... はビットマップが work_mem に収まらずページ単位まで粗くした分です。lossy に入ったページは丸ごと読み直し、条件を全行に対して評価し直します。work_mem を上げれば解消します。

16,070 行ではなく、48,210 行です。

Parallel Seq Scan の rows=16070 は、ワーカー 1 本あたりの平均です。loops=3 が示すとおり、実際に読んだのは 3 本分。16,070 × 3 = 48,210 行が全体の量で、それが Gather の行に現れています。

loops が 1 より大きければ 1 回あたりの平均、という原則はここでも同じです。違うのは、ループの正体が繰り返しではなく並列だという点だけです。

ワーカーの本数は、リーダーを含めて数えます。Workers Launched が 2 でも loops は 3 です。問い合わせを起こしたプロセス自身も、待つのではなく分担に加わるためです。

Memoize は、内側の結果を覚えます。

Nested Loop の内側で同じキーが何度も引かれる場合、PostgreSQL は結果をハッシュ表に覚えておき、2 回目以降はそこから返します。実行計画では次のように出ます。

Hits が大きければ、内側の走査はその回数だけ省けています。逆に Evictions が増えていれば、覚えきれずに捨てているということです。この表の大きさは work_mem × hash_mem_multiplier で決まります。

Misses が Hits と同じくらいなら、効いていません。キーがほとんど重複していないということなので、この場合に見るべきは Memoize ではなく、外側の行数の見積もりです。

WITH 句は、いつも実体化されるわけではありません。

PostgreSQL 12 より前は、WITH は必ず先に実行され、結果を丸ごと保持していました。上位の条件は中へ入らず、これを利用して意図的に評価順を固定する書き方も広く使われていました。

12 以降は、参照が 1 回だけで副作用がなく、再帰でもない WITH は本体へ展開されます。展開されれば上位の条件が中へ押し込まれ、インデックスも使われます。このとき実行計画に CTE Scan は現れません。

同じ結果を何度も参照するなら実体化、1 度しか使わず絞り込みを効かせたいなら展開が有利です。CTE Scan の loops が大きければ、実体化した結果を繰り返し走査しています。

13 個あるうち、2 個しか読んでいません。

月ごとに 13 個のパーティションを持つ表ですが、実行計画に並んでいるのは 2 個だけです。残りは条件に合う行がないと判断され、実行計画から取り除かれました。

枝刈りには 2 つの時点があります。条件の値が計画時に分かっていれば、そのとき除かれます。この場合、除かれたパーティションは実行計画に痕跡すら残しません。

値が実行時にしか決まらない場合は、実行しながら除きます。その結果が Subplans Removed: 11 です。プレースホルダを使ったクエリや、副問い合わせの結果で絞る場合がこれにあたります。

ANALYZE なしの EXPLAIN では、全パーティションが並びます。実行時の枝刈りは実行しないと起きないためです。枝刈りを確かめたいときは、必ず EXPLAIN (ANALYZE, BUFFERS) で見てください。

なぜ 1 段目の誤差が致命的になるのか

プランナーは、条件ごとの選択率を掛け合わせて行数を見積もります。しかし、2 つの条件に相関があると、それぞれが独立しているという前提が崩れ、実際よりも小さく見積もることがあります。

例えば、「都道府県 = 東京」と「市区町村 = 渋谷区」は独立した条件ではありません。それぞれの選択率を単純に掛けると、該当する行数を実際よりもはるかに少なく見積もってしまいます。その結果、Nested Loop が選ばれ、内側の処理を数万回も繰り返すことになります。

下のスライダーでは、最初の見積もりが実測値とどれだけずれたとき、2 回の結合を経て誤差がどこまで膨らむかを確認できます。

まず、統計が古くないかを確かめます。

大量の投入や削除の直後は、自動処理が追いつく前に統計が実態から離れます。pg_stat_user_tables の last_analyze と last_autoanalyze を見て、最後に集計された時刻を確認してください。

ANALYZE を実行しただけで見積もりが直り、計画が変わることは珍しくありません。設定に手を付ける前に、ここを確かめます。

統計の細かさを、列ごとに上げます。

既定では、1 列につき 100 個の代表値と度数分布を保持します（default_statistics_target）。値の種類が極端に多い列や、偏りの大きい列では、この粒度で足りません。

全体設定を上げると、すべての表の集計時間と保持量が増えます。問題の列だけを上げるのが基本です。効いたかどうかは pg_stats の n_distinct と most_common_vals で確かめられます。

列どうしの関係は、単独の統計では表せません。

プランナーは既定で、条件どうしが互いに独立だと仮定します。都道府県が「神奈川県」である行が全体の 7%、市区町村が「横浜市」である行が 3% なら、両方を満たす行は 0.21% と見積もります。実際には横浜市はすべて神奈川県にあるので、正しくは 3% です。14 倍の過小見積もりです。

この関係を教えるのが拡張統計です。

dependencies は「片方が決まれば他方も絞られる」関係、ndistinct は組み合わせの種類数、mcv はよく出る組み合わせを保持します。作成後は必ず ANALYZE を実行してください。

条件を式で書くと、統計から外れます。

WHERE date_trunc('month', created_at) = '2026-09-01' のように列を加工すると、created_at の統計は使えません。プランナーは決め打ちの推定値を使うため、大きく外れます。

式インデックスを作ると、その式そのものの統計が集められます。

より確実なのは、列を加工せずに範囲で書くことです。created_at >= '2026-09-01' AND created_at < '2026-10-01' と書けば、元の列の統計がそのまま使えます。

4 つの数字を読み分けます。

shared hit は共有バッファから読めたページ、read はそこになくディスク（または OS のキャッシュ）へ取りに行ったページです。同じクエリの 1 回目と 2 回目で時間が違う理由は、ここに現れます。

dirtied は内容を変更したページ、written は書き出したページです。SELECT でも、行の可視性の記録を更新して dirtied が増えることがあります。

temp が出たら、メモリ不足です。上の例では Sort Method: external merge と temp read/written が同時に出ています。ソートがメモリに収まらず、一時ファイルへ書き出しています。

243 ms のうち、202 ms が準備です。

実際にデータを読んで集計したのは 41 ms ほどで、残りはコンパイルに費やされています。この時間は Execution Time に含まれます。Planning Time ではありません。実行計画の下だけを見て「集計が遅い」と判断すると、原因を取り違えます。

4 つの内訳のうち、時間を食いやすいのは Optimization と Emission です。Deforming は行から列を取り出す処理、Expressions は WHERE 句や集計式の評価を指します。

並列実行では、ワーカーごとにコンパイルされます。表示される時間はその合計なので、ワーカー 3 本なら 3 倍の値が並びます。実際に待たされる時間は 1 本分ですが、CPU はその分使われています。

判断の材料は、実測ではなく見積もりです。

JIT が動くかどうかは、プランナーが出した総コストだけで決まります。実際に何行処理するかは関係ありません。

ここに、見積もりの誤差が直結します。実際は 100 行しか返らないのに、統計が古くて 500 万行と見積もっていれば、コストは閾値を軽く超え、100 行のためにコンパイルが走ります。JIT の無駄打ちは、多くの場合、統計の問題として現れています。

疑ったら、まず切って比べます。

これで速くなるなら、原因は JIT です。SET jit_above_cost = 500000; のように閾値を上げれば、本当に重いクエリだけを対象にできます。判断の目安は、コンパイルに費やす時間を、実行時間の短縮で取り返せるかです。

取り返せるのは、数百万行を読みながら式を繰り返し評価するような分析系のクエリです。数十ミリ秒で終わる問い合わせが大量に飛ぶ用途では、閾値を上げるか無効にしたほうが、全体としては速くなります。

列とパーティションが多いほど、Functions が増えます。数百の列を扱うクエリでは生成される関数が数百個に達し、コンパイルだけで秒単位になることがあります。実行計画に JIT: の節を見つけたら、まず Functions の数と Total を確かめてください。