実行計画を読む順番（木構造・内側から外側へ）

上から順に実行される、ではない

実行計画でいちばん多い誤読がこれです。実行計画は木構造で、いちばん上の行が最後に実行されます。

 Nested Loop  (cost=0.85..28.26 rows=4 width=17) (actual time=0.041..0.051 rows=4.00 loops=1)
   ->  Index Scan using members_pkey on members m  (cost=0.42..8.44 rows=1 width=17) (actual time=0.022..0.022 rows=1.00 loops=1)
         Index Cond: (id = 42)
         Index Searches: 1
   ->  Index Scan using orders_s_member_idx on orders_s o  (cost=0.43..19.78 rows=4 width=8) (actual time=0.017..0.024 rows=4.00 loops=1)
         Index Cond: (member_id = 42)
         Index Searches: 1
 Planning Time: 0.311 ms
 Execution Time: 0.099 ms

この計画は、上から読むとこう書いてあります。

1. Nested Loop
2. Index Scan using members_pkey on members m
3. Index Scan using orders_s_member_idx on orders_s o

実際に動く順番は 2 → 3 → 1 です。members から 1 行取り、その id を使ってorders_s を引き、その結果を Nested Loop が組み合わせます。

読み方は 3 つの規則だけ

1. 矢印（->）が付いている行がノード

矢印が付いていない行は、そのすぐ上のノードに対する補足です。Index Cond: Filter: Index Searches: Sort Method: Buffers: などがこれにあたります。 ノードではないので、読む順番を考えるときは無視して構いません。

Index Searches: は PostgreSQL 18 で増えた行で、 そのノードがインデックスを何回探しに行ったかを表します。 繰り返し実行されるノードでは loops と同じ数になることが多く、「何回まわったか」を裏から確かめる材料になります。ただしこの行だけは 1 回あたりではなく累計です。だから loops と同じ数になります。 17 以前の出力を見慣れている人には見覚えのない行なので、先に触れておきます。

2. インデントが深い方が子

あるノードより右にずれている矢印が、そのノードの子です。 同じ深さに矢印が 2 つ並んでいれば、そのノードは子を 2 つ持っています （結合ノードがこれです）。

3. 子が先に動き、親は結果を受け取る

だからいちばん深いところから読み始めます。いちばん上の行は、全部終わったあとに最後の仕上げをするノードです。

子が 2 つあるとき

結合のノードは子を 2 つ持ちます。上が外側、下が内側です。

 Hash Join  (cost=4534.20..40595.24 rows=40310 width=17) (actual time=6.428..138.374 rows=40000.00 loops=1)
   Hash Cond: (o.member_id = m.id)
   ->  Seq Scan on orders_s o  (cost=0.00..30811.00 rows=2000000 width=8) (actual time=0.047..51.442 rows=2000000.00 loops=1)
   ->  Hash  (cost=4407.95..4407.95 rows=10100 width=17) (actual time=6.344..6.345 rows=10000.00 loops=1)
         Buckets: 16384  Batches: 1  Memory Usage: 636kB
         ->  Bitmap Heap Scan on members m  (cost=114.70..4407.95 rows=10100 width=17) (actual time=0.821..5.602 rows=10000.00 loops=1)
               Recheck Cond: (city = 'city-7'::text)
               Heap Blocks: exact=4167
               ->  Bitmap Index Scan on members_city_idx  (cost=0.00..112.17 rows=10100 width=0) (actual time=0.484..0.484 rows=10000.00 loops=1)
                     Index Cond: (city = 'city-7'::text)
                     Index Searches: 1
 Planning Time: 0.456 ms
 Execution Time: 139.601 ms

この Hash Join は、Seq Scan on orders_s（外側）と Hash（内側）を子に持っています。Hash はさらに Bitmap Heap Scan on members を子に持っています。

動く順番は内側からです。先に members を読んでハッシュ表を作り、 そのあと orders_s を流しながら突き合わせます。 なぜその順番なのかは結合の種類に書いてあります。

いちばん上は「最後にやること」

木のいちばん上に来やすいノードには決まった顔ぶれがあります。

• Limit — 必要な件数だけ取ったら止める
• Sort — ORDER BY のための並べ替え
• Aggregate / GroupAggregate / HashAggregate — 集約

これらが上にあるということは、それ以外の全部が先に終わっているということです。

Limit は少し特別で、下のノードを途中で止められます。10 件そろった時点で「もういい」と言えるので、 下の actual rows が 10 で止まっていることがあります。

逆に、下のノードが 100 万行返しているのに Limit 10 が付いていたら、 止められなかったという意味です。あいだに Sort や集約が挟まっていると、 並べ替えるために全部読まないと 1 行目が決まらないためです。この場合、100 万行ぶんの仕事はもう終わっています。

ここまでで、あの計画のどこが読めるようになったか

セクションの最初のページに出した 2.16 秒の計画は、 全部で 25 行あります。その骨格はもう読めます。

• 1 行目の Limit が最後に実行される（いちばん上 = 最後）
• 19 行目のいちばん深いノードが最初に動く（いちばん深いところ = 最初）
• 矢印が付いていない行は補足で、ノードではない

まだ読めないのは数字の意味だけです。cost はcost と rows の意味、actual time と loops はEXPLAIN ANALYZE の見方へ。