JPUGしくみ＋アプリケーション勉強会（第20回）

Explaining EXPLAIN 第２回

第20回しくみ+アプリケーション勉強会
(2011年6月4日)

PostgreSQLしくみ分科会
中西剛紀

Explaining Explain p.10

Explaining → プラン演算子
始動始動
演算子関連処理演算子関連処理
コストコスト
Seq Scan 表スキャン無 Result 関数スキャン無
Index Scan 無 DISTINCT
Unique 有
Bitmap Index Scan 索引スキャン有 UNION
Bitmap Heap Scan 有 LIMIT
Limit 有
OFFSET
Subquery Scan 副問合せ無
count, sum,
Tid Scan ctid = ... 無 Aggregate 有
avg, stddev
Function Scan 関数スキャン無
Group GROUP BY 有
Nested Loop 結合無
Append UNION 無
Merge Join 結合有
Materialize 副問合せ有
Hash Join 結合有
INTERCECT
Sort ORDER BY 有 SetOp 有
EXCEPT
Hash 有
2


Seq Scan 演算子 : 例題
=# EXPLAIN SELECT oid FROM pg_proc;
QUERY PLAN
------------------------------------------
Seq Scan on pg_proc
(cost=0.00..87.47 rows=1747 width=4)

• 最も基本。単に表を最初から最後へとスキャンする
• 条件にかかわらず各行をチェックする
• 大きなテーブルはインデックススキャンの方が良い
• コスト(開始コスト無し), 行(タプル), 幅(oid)
• トータルコストは 87.47
3

Seq Scan について
• テーブルを最初から最後までチェックして必要な行を探す。
• 検索条件に合致するインデックスがない場合はこれしかない。
• インデックスが使えても対象行が多い場合は Seq Scan に。
⇒ オプティマイザがコスト計算した結果を比較して判断する。

id列のインデックステーブル Seq Scan のコスト
id = 1
= DISK I/O コスト + CPU コスト
= テーブル全ページ数×sequential_page_cost
id = 11
+ テーブル全行数×cpu_tuple_cost
id = 34
+ テーブル全行数×cpu_operator_cost
id = 45
使わない・テーブル全ページ数 pg_class の relpages
・・・
・テーブル全行数 pg_calss の reltuples
先頭行から順に走査・シーケンシャルにDISK1ページを読むコスト
（最後の行まで見る必要あり） sequential_page_cost = 1
・ 1行を走査するCPUコスト
cpu_tuple_cost = 0.01
・計算1回のCPUコスト (条件絞りこみ) 4
cpu_operator_cost = 0.0025


Index Scan 演算子
=# EXPLAIN SELECT oid FROM pg_proc WHERE oid=1;
QUERY PLAN
-----------------------------------------------------
Index Scan using pg_proc_oid_index on pg_proc
(cost=0.00..5.99 rows=1 width=4)
Index Cond: (oid = 1::oid)

• Index Condが無い場合は、ソートの代わり
として使われるインデックス順のフルスキャ
ンを表す
5

Index Scan について
• 検索条件に合致するインデックスがあれば検討する。
• 通常は対象行が少なければこちらが選択される。
• インデックスとテーブルを交互にアクセスする。
Index Scan のコスト
id列のインデックステーブル
= インデックスI/Oコスト + テーブルI/Oコスト
id = 1
+ インデックスCPUコスト + テーブルCPUコスト
id = 11
１１１ 45 100 id = 34 インデックスI/Oコスト
id = 45 = 必要ページ数×sequential_page_cost（1）
検索条件に合う・・・
リーフノードを探索テーブルI/Oコスト
必要な行に = 必要行数×(1～4) ※
ランダムアクセス
インデックスCPUコスト
= 必要行数×cpu_index_tuple_cost（0.005）
※
テーブルCPUコスト
アクセスページがメモリサイズ
= 必要行数×cpu_tuple_cost（0.01）
(effective_cache_size)の
何倍かでアクセスコストは変化 6

必要行数って何？
• 指定条件を満たす行数
• Explain の実行結果で「rows=100」とか表示される値。
• プランナがテーブルの統計情報から行数を予測。
⇒ 実際に検索した時の行数とは異なる。
• 必要行数 = 選択度×テーブル行数

• 「選択度」は対象カラムの統計情報を使って計算
• 各カラム値の分布は pg_stats（pg_statistic）でわかる。
⇒ ANALYZE時に収集した情報が格納されている。

7

選択度の計算
• 計算方法は2通り。
• テーブル内で多く出現（重複）する値を条件指定した場合
Common値(MCV: Most Common Values)
# SELECT most_common_vals, most_common_freqs FROM pg_stats
WHERE tablename='tenk1' AND attname='stringu1';
出現数/テーブル行数
most_common_vals | {EJAAAA,BBAAAA,CRAAAA,FCAAAA,FEAAAA,
GSAAAA,JOAAAA,MCAAAA,NAAAAA,WGAAAA}
most_common_freqs | {0.00333333,0.003,0.003,0.003,0.003,0.003,0.003,0.003,0.003,0.003}
※PostgreSQL 9.0.3 のマニュアル第56章の例を引用

• 実際にその値が入っている行の出現頻度が
分かっているので、そのまま使用する。
上記の例でテーブルtenk1の全行数を1000件とすると、
「Stringu1=‘MCAAAA’」の行数は「1000×0.003 = 3」行と推測できる。

8

選択度の計算
• Common値以外の値を条件指定した場合
• 一致検索（WHERE stringu1 = ‘IAAAA’）
選択度 = MCV値を除いた行数 / カーディナリティ
⇒ MCV値以外はテーブル内に均等に出現すると仮定。
• 範囲検索 (WHERE stringu1 < ‘IAAAA’)
MCV値以外のヒストグラムを利用
# SELECT histogram_bounds FROM pg_stats
WHERE tablename='tenk1' AND attname='stringu1'; 各帯のサンプル数が均一化
されるように帯幅を調整
histogram_bounds
--------------------------------------------------------------------------------
{AAAAAA,CQAAAA,FRAAAA,IBAAAA,KRAAAA,NFAAAA,PSAAAA,SGAAAA,
VAAAAA,XLAAAA,ZZAAAA}

※PostgreSQL 9.0.3 のマニュアル第56章の例を引用

• 指定範囲に含まれるMVC値の選択度と、
ヒストグラムから導出した非MVC値の選択度を加える。
9


Bitmap Scan 演算子
test=# EXPLAIN SELECT * FROM q3c,q3c as q3cs
WHERE (q3c.ipix>=q3cs.ipix-3 AND q3c.ipix<=q3cs.ipix+3)
OR (q3c.ipix>=q3cs.ipix-1000 AND q3c.ipix<=q3cs.ipix-993);
QUERY PLAN
------------------------------------------------
Nested Loop
-> Seq Scan on q3c q3cs
-> Bitmap Heap Scan on q3c
-> BitmapOr
-> Bitmap Index Scan on ipix_idx
-> Bitmap Index Scan on ipix_idx

• 8.1で追加された
• BitmapOr, BitmapAnd で複数のビットマップを合体
• リレーションの”ビットマップ“をメモリ内で作成する
10

Bitmap Scan について
• インデックスを有効に使って検索効率を向上させる機構
• ORで結合した条件式を使った検索に効果大
WHERE (id1 BETWEEN 10 AND 40) OR (id2 BETWEEN 20 AND 70)

Bitmap Index Scan BitmapOr Bitmap Heap Scan
id1列のインデックス 0
1 ビットマップ
1 同士でOR演算テーブル
１１１ 34 45
0 1 id1 = 1, id2 = 33
・・ 1 id1 = 11, id2 = 55
条件を満たす行（TID）を
1 id1 = 34, id2 = 77
ビットマップとして生成
1 0 id1 = 45, id2 = 99
id2列のインデックス
1 ・・・・・
0 ビットONの行を取得
0
33 55 77 99
・・同一ページ内に複数の対象行が
ある場合、まとめて取得できるので、
11
I/Oコストが有利になる。

work_mem と lossy storage
• ビットマップは作業メモリ(work_mem)上に作成する。
• 通常、ビットマップには行の位置を表すTIDを持つ。
– work_mem = 1MB で 500万行ほどしか持てない。
• work_mem に収まらないサイズの場合、
lossy storage モードへ移行してビットマップサイズを縮小
– 1行を1ビットで表現 ⇒ 1ページを１ビットで表現（1MBで64GBまでOK）
– 取得データから条件を満たさないデータを排除するコストが必要
通常モード lossy storage モード
TID（0, 1）
0 TID（0, 1） 1 ページ0
TID（0, 2）
1 TID（0, 2） 0 ページ1
TID（0, 3）
1 TID（0, 3）・・・・
・・
0 TID（1, 1）
ページ単位の
行データを取ってから
0 TID（1, 2）ビットマップに
不要行を削除する
0 TID（1, 3）変更してサイズ縮小
・・・・ 12


Tid Scan 演算子
=# EXPLAIN SELECT oid FROM pg_proc WHERE ctid = '(0,1)';
QUERY PLAN
------------------------------------------------------
Tid Scan on pg_proc (cost=0.00..4.01 rows=1 width=4)
Filter: (ctid = '(0,1)'::tid)

• カラムタプルID
• “ctid=”がクエリに指定された場合のみ使われる
• 滅多に使わない、非常に速い

13

TIDとは
• システムによって暗黙的に定義されたシステム列。
• 行データの位置（格納ブロック,アイテムポインタ位置）を示す。

索引・・・キー値：1000 TID=(5,1) キー値：1001 TID=(5,2) ・・・
ブロック番号 5
表ブロック(ページ)ヘッダアイテムポインタ1 アイテムポインタ2 ・・・

・・・行データ2（キー値：1001）行データ1（キー値：1000）

TIDを１つ指定して検索する場合のコスト：
random_page_cost（4.00）+ cpu_tuple_cost（0.01） = 4.01

ただし、行のctidはレコードが更新されたり、VACUUM FULLで移動させられると
変わるので、直接TIDを指定して検索するケースは少ないと思われる。
14


Nested Loop 演算子
=# SELECT * FROM pg_foo JOIN pg_namespace
ON (pg_foo.pronamespace=pg_namespace.oid);
QUERY PLAN
---------------------------------------------------------------
Nested Loop (cost=1.05..39920.17 rows=5867 width=68)
Join Filter: ("outer".pronamespace = "inner".oid)
-> Seq Scan on pg_foo (cost=0.00..13520.54 rows=234654 width=68)
-> Materialize (cost=1.05..1.10 rows=5 width=4)
-> Seq Scan on pg_namespace (cost=0.00..1.05 rows=5 width=4)

• ２つのテ=ブルの結合(２つの入力セット)
• INNER JOIN と LEFT OUTER JOIN の使用
• 「外部」テーブルをスキャンし、「内部」テーブルにマッチするものの発見
• 開始コスト無し
• インデックスが無い場合遅い問い合わせになる可能性、特にselect句に関
数がある場合
15

Nested Loop（入れ子ループ）
• 一番単純な結合方式
• 外側テーブル1行毎に内側テーブルを走査する。
• 外側テーブルの件数小&内側テーブルに
結合キーのインデックスがあるケースに有効。

外側テーブル内側テーブル • 事前準備（初期コスト）は不要。
（N件）（M件）
• 規模が大きくなるにしたがってコストは膨らむ。
2 2
7 1 • 計算量は O（N×M）。
4 4
9 3
先頭から1行外1行毎に
ずつスキャン全件スキャン

16


Merge Join 演算子
=# EXPLAIN SELECT relname,nspname FROM pg_class left join
pg_namespace ON (pg_class.relnamespace = pg_namespace.oid);
QUERY PLAN
-----------------------------------------------------------------
Merge Right Join (cost=14.98..17.79 rows=186 width=128)
Merge Cond: ("outer".oid = "inner".relnamespace)
-> Sort (cost=1.11..1.12 rows=5 width=68)
Sort Key: pg_namespace.oid
Sort Key: pg_class.relnamespace
-> Seq Scan on pg_class (cost=0.00..6.86 rows=186 width=68)
• 二つのデータセットをJOINする：outerとinner
• Merge Right JoinとMerge In Joinがある
• データセットはあらかじめソートされていなければならず、また両方同
時に走査される。
17

Merge Join (ソートマージ)
• 事前に両方のテーブルを結合キーでソートする。
• 両方のテーブルを先頭からマッチングしていく。
⇒ テーブルを1回調べればよく、テーブルの走査回数減
• 処理対象の行が多いケースで有効
外側テーブル内側テーブル
（N件）（M件） • ソートさえできれば速いが。。。
2 2 1 2 ⇒ インデックスがない列が結合キー
7 4 2 1
の場合はコスト大。
4 7 3 4
9 9 4 3
• 計算量は O（NlogN + MlogM）。

結合キーで両テーブルを結合キーで
事前にソートキー順に事前にソート
マッチング

18


Hash & Hash Join 演算子
=# EXPLAIN SELECT relname, nspname FROM pg_class JOIN
pg_namespace ON (pg_class.relnamespace=pg_namespace.oid);
QUERY PLAN
-----------------------------------------------------------------
Hash Join (cost=1.06..10.71 rows=186 width=128)
Hash Cond: ("outer".relnamespace = "inner".oid)
-> Seq Scan on pg_class (cost=0.00..6.86 rows=186 width=68)
-> Hash (cost=1.05..1.05 rows=5 width=68)

• Hashは、異なる Hash Join演算子で使用されるハッシュテーブルを作
成する
• 一方の入力からハッシュテーブルを作成し、二つの入力を比較する
• INNER JOIN、OUTER JOINと同時に使われる
• ハッシュの作成にはスタートアップコストが伴う
19

Hash Join（ハッシュ値マッチング）
• 事前に内側テーブルのハッシュ表を作成。
⇒ ハッシュ表を作成する初期コストが必要。
• 外側テーブルとハッシュ表を突き合わせる。
• ハッシュ表がメモリ(work_mem)に収まらないと性能劣化。

外側テーブルハッシュ表内側テーブル
（N件）（メモリ内）（M件） • 一度ハッシュ表を作ってしまえば、
2 2 メモリ内で検索を行えるので
7 1 ハッシュ表の検索は高速。
4 4
• 計算量のオーダーは O（N+M）。
9 3

先頭から1行ハッシュ表を
ずつスキャン事前に作成

結合キーのハッシュ値で
ハッシュ表を検索
20

Explain実行例
// accounts（100万件）、branches（10件）をJOIN。最初はHash Join を選択。
# EXPLAIN SELECT * FROM accounts a INNER JOIN branches b ON a.bid = b.bid WHERE a.aid < 10000;
-------------------------------------------------------------------------------------------------------------
accounts_pkey をインデックスス
Hash Join (cost=1.23..617.37 rows=10425 width=373)
キャンしながらハッシュ表とJOIN
Hash Cond: (a.bid = b.bid)
-> Index Scan using accounts_pkey on accounts a (cost=0.00..472.80 rows=10425 width=97)
Index Cond: (aid < 10000)
-> Hash (cost=1.10..1.10 rows=10 width=276) branches を Seq Scan しながら
-> Seq Scan on branches b (cost=0.00..1.10 rows=10 width=276) ハッシュ表作成

// Hash Joinを無効にするとMerge Joinを選択。（SET enable_hashjoin=off;）
-------------------------------------------------------------------------------------------------------------------------
各ソート結果をJOIN。
Merge Join (cost=1740.32..1922.80 rows=10425 width=373) （ほとんどbranchesのソートコスト）
Merge Cond: (b.bid = a.bid)
-> Sort (cost=1.27..1.29 rows=10 width=276) bidでbranchesをソート
Sort Key: b.bid
-> Seq Scan on branches b (cost=0.00..1.10 rows=10 width=276)
-> Materialize (cost=1739.05..1791.17 rows=10425 width=97)
-> Sort (cost=1739.05..1765.11 rows=10425 width=97) bidでaccountsをソート
Sort Key: a.bid （索引がなくて遅い）
Index Cond: (aid < 10000) aidで対象を絞り込み。
// さらに Merge Join も無効にすると (しかたなく) Nested Loop を選択。（SET enable_mergejoin=off;）
-------------------------------------------------------------------------------------------------------------
Nested Loop (cost=0.00..2037.67 rows=10425 width=373)
accounts はインデックスを使ってスキャン
Join Filter: (a.bid = b.bid)
Index Cond: (aid < 10000)
-> Materialize (cost=0.00..1.15 rows=10 width=276) 21
branchesが外部表
-> Seq Scan on branches b (cost=0.00..1.10 rows=10 width=276)


Result 演算子
=# EXPLAIN SELECT oid FROM pg_proc WHERE 1+1=3;
QUERY PLAN
--------------------------------------------
Result (cost=0.00..87.47 rows=1747 width=4)
One-Time Filter: false
-> Seq Scan on pg_proc
(cost=0.00..87.47 rows=1747 width=4)

• 非テーブル問い合わせ
• テーブルを参照せずに結果が得られる場合

22


Sort 演算子
=# EXPLAIN SELECT oid FROM pg_proc ORDER BY oid;
QUERY PLAN
---------------------------------------------
Sort (cost=181.55..185.92 rows=1747 width=4)
Sort Key: oid
(cost=0.00..87.47 rows=1747 width=4)

• 明示的なソート : ORDER BY句
• 暗黙的なソート : Unique, Sort-Merge Join など
• 開始コストを持っている: 最初の値はすぐには返却
されない
23

Sort について
• データが作業メモリ（work_mem）に収まればクイックソート
– DISK I/Oが発生しない。高速。
• 作業メモリに収まらなければ外部ソートを選択
– アルゴリズムは「マージソート」
– DISK I/Oが発生するのでクイックソートより低速。
– I/Oコストは対象データと work_mem のサイズで変わってくる。
work_memに収まるサイズ毎にソートを繰り返すから。多分。。。
– 詳しくは /src/backend/optimizer/path/costsize.c の cost_sort 参照。

【対象データ < work_mem】【対象データ > work_mem】
work_mem work_mem
• 対象データを全て以下を繰り返す。
7 2 メモリに保持 7 2 8 1 • データの一部を
4 4 • メモリ上でクイック 4 4 1 3 メモリに保持
9 7 ソートを実行 9 7 3 5 ・・・ • メモリ上でソート実行
2 9 2 9 5 8 • ソート結果を
DISKに戻す

DISK DISK DISK
24

Sortの実行例
# EXPLAIN ANALYZE SELECT * FROM pgbench_accounts ORDER BY bid;
--------------------------------------------------------------------------------------------------------------------------
(actual time=882.522..1186.626 rows=1000000 loops=1)
Sort Key: bid
Sort Method: external sort Disk: 104600kB ソート対象が大きいので外部ソート
-> Seq Scan on pgbench_accounts (cost=0.00..26394.00 rows=1000000 width=97)
Total runtime: 1264.377 ms
※ ログに一時ファイル作成状況を表示（postgresql.conf の log_temp_files = 0）
LOG: temporary file: path "base/pgsql_tmp/pgsql_tmp32001.0", size 107110400
STATEMENT: EXPLAIN ANALYZE SELECT * FROM pgbench_accounts ORDER BY bid;

※ work_mem を1⇒200MBに拡張して実行してみる
# SET work_mem=‘200MB’;
# explain analyze select * from pgbench_accounts order by bid;
--------------------------------------------------------------------------------------------------------------------------
Sort Key: bid
Sort Method: quicksort Memory: 165202kB メモリに収まったのでクイックソート
25


Unique 演算子
=# EXPLAIN SELECT distinct oid FROM pg_proc;
QUERY PLAN
--------------------------------------------------
Unique (cost=181.55..190.29 rows=1747 width=4)
Sort Key: oid
(cost=0.00..87.47 rows=1747 width=4)
• 入力セットから重複する値を削除
• 行の並べ替えはせず、単に重複する行を取り除く
• 入力セットは予めソート済み (Sort演算子の後に行う)
• タプルコストごとに「CPU演算」×2
• DISTINCT と UNION で使用される
26

Unique演算子について
• 事前に対象データをソートする初期コストが必要。
• DISTINCT, UNION句で使用されるが、
実行コストによって HashAggregate 演算子と使い分け。
⇒ バージョン8.3まではこのプラン選択を行わなかったため、
「DISTINCTをGROUP BYに置き換える」チューニング作法があった。
⇒ バージョン8.4からはプランナが自動的に選択するようになった。
Sort （前処理） Unique
2 2 2

4 2 4

7 4 7

9 4 9

4 7

2 9

重複排除する対象の重複行を排除
列でデータをソート
27

Unique演算子の実行例
// テーブル pgbench_tellers (100件) を DISTINCT 句付で SELECT
# EXPLAIN SELECT DISTINCT tid FROM pgbench_tellers;
QUERY PLAN
-------------------------------------------------------------------------------------------------------------------
HashAggregate (cost=2.25..3.25 rows=100 width=4)
-> Seq Scan on pgbench_tellers (cost=0.00..2.00 rows=100 width=4)

// HashAggregate を無効 (set enable_hashagg=off) にして実行してみる。
# EXPLAIN SELECT DISTINCT tid FROM pgbench_tellers;
QUERY PLAN
-------------------------------------------------------------------------------------------------------------------------
Unique (cost=5.32..5.82 rows=100 width=4)
-> Sort (cost=5.32..5.57 rows=100 width=4) ソートのコストが大部分を占めている
Sort Key: tid
Sort Method: quicksort Memory: 29kB
-> Seq Scan on pgbench_tellers (cost=0.00..2.00 rows=100 width=4)

28


Aggregate 演算子
=# EXPLAIN SELECT count(*) FROM pg_proc;
QUERY PLAN
--------------------------------------------------------------
Aggregate (cost=91.84..91.84 rows=1 width=0)
-> Seq Scan on pg_proc (cost=0.00..87.47 rows=1747 width=0)

• count, sum, min, max, avg, sttdev, varianceを使用
• GROUP BY 使用の場合差異が認められることがあり

=# EXPLAIN SELECT count(oid), oid FROM pg_proc GROUP BY oid;
QUERY PLAN
-------------------------------------------------------------

29


GroupAggregate 演算子
=# EXPLAIN SELECT count(*) FROM pg_foo GROUP BY oid;
QUERY PLAN
-----------------------------------------------------------------
GroupAggregate (cost=37442.53..39789.07 rows=234654 width=4)
Sort Key: oid
-> Seq Scan on pg_foo (cost=0.00..13520.54 rows=234654 width=4)

• GROUP BYを使用し、より大きな結果セット上に
集約を行う

30

Aggregate演算子
• 複数の行を１行に集約する処理を行う。
– GROUP BY & 集約関数（COUNT, SUM, MAX, MIN）

• Aggregate演算子
– 単純な集約処理。COUNT(*) とか。
– CPUコスト = cpu_operator_cost (0.0025) × 行数

• GroupAggregate演算子
– 事前に対象データをソートする初期コストが必要
– HashAggregateに比べて低速なケースが多い。

• HashAggregate演算子
– バージョン7.4より実装。
– メモリ中にハッシュ表を作成する。高速。
– 対象データが作業メモリ（work_mem）内に収まる必要がある。
⇒ 収まらなかったら GroupAggregate を選択する。
31

Aggregate演算子の実行例
// work_mem を1MBにした状態で実行 100万件。Indexなし
# EXPLAIN ANALYZE SELECT MAX(aid) FROM pgbench_accounts GROUP BY aid ;
--------------------------------------------------------------------------------------------------------------------------
GroupAggregate (cost=153400.84..173400.84 rows=1000000 width=4)
Sort Key: aid
Sort Method: external sort Disk: 13688kB メモリが小さいと GroupAggregate を選択
ハッシュ表がメモリに収まれば
// work_mem を100MBに広げて実行
HashAggregate を選択
# EXPLAIN ANALYZE SELECT MAX(aid) FROM pgbench_accounts GROUP BY aid ;
--------------------------------------------------------------------------------------------------------------------------

32


Limit 演算子
=# EXPLAIN SELECT oid FROM pg_proc LIMIT 5;
QUERY PLAN
------------------------------------------
Limit (cost=0.00..0.25 rows=5 width=4)
(cost=0.00..87.47 rows=1747 width=4)

• 行は指定された数に等しい
• 最初の行を即時に返す
• 少量の開始コスト追加でオフセットの扱いも可
=# EXPLAIN SELECT oid FROM pg_proc LIMIT 5 OFFSET 5;
QUERY PLAN
------------------------------------------
(cost=0.00..87.47 rows=1747 width=4) 33

Limit演算子の実行例
# EXPLAIN SELECT aid FROM pgbench_accounts LIMIT 10; ・・・(A)
--------------------------------------------------------------------------------

# EXPLAIN SELECT aid FROM pgbench_accounts LIMIT 10 OFFSET 10; ・・・(B)
--------------------------------------------------------------------------------

# EXPLAIN SELECT aid FROM pgbench_accounts LIMIT 10 OFFSET 20; ・・・(C)
--------------------------------------------------------------------------------

(A) 1 先頭10件を (B) 1 先頭10件は (C) 1 先頭20件は
取得するコスト読み飛ばす読み飛ばす
・・・・・・・・・
初期コスト 0.00 （コスト0.26）（コスト0.53）
10 総合コスト 0.26 10 10

11 11 11～20件目を 11
取得するコスト
・・・・・・・・・
この先初期コスト 0.26
21～30件目を
20 見る必要なし 20 総合コスト 0.53 20
21 21 21 初期コスト 0.53
この先
・・・・・・見る必要なし・・・総合コスト 0.79
Seq Scan
30 30 30 34
のコスト
26,394 ・・・・・・・・・この先
見る必要なし

Limit演算子の実行例
# EXPLAIN SELECT aid FROM pgbench_accounts ORDER BY aid LIMIT 10;
--------------------------------------------------------------------------------------
Sort Key: aid

(ORDER BYなし) (ORDER BYあり)

先頭10件を Sort 結果の先頭行が
1 1 先頭10件を
取得するコスト取れるまでは待つ。
・・・・・・
初期コスト 0.00 初期コスト 48003.64
10 総合コスト 0.26 10 総合コスト 48003.67
11 11 Sort が完了するまで
・・・この先・・・待つ必要はない。
20 見る必要なし 20
21 21
・・・・・・
Seq Scan Seq Scan Sortのコスト
のコスト 30 のコスト 30 初期コスト 48003.64
26,394 ・・・ 26,394 ・・・
総合コスト 50503.64

35


Append 演算子
=# EXPLAIN SELECT oid FROM pg_proc
UNION ALL SELECT oid ORDER BY pg_proc;
QUERY PLAN
--------------------------------------------------------------
Append (cost=0.00..209.88 rows=3494 width=4)

• UNION (ALL) によるトリガー, 継承
• 開始コスト無し
• コストは単に全ての入力の合計

36


Function Scan 演算子
=# CREATE FUNCTION foo(integer) RETURNS SETOF integer AS
$$
select $1;
$$
LANGUAGE sql;

=# EXPLAIN SELECT * FROM foo(12);
QUERY PLAN
------------------------------------------------------------
Function Scan on foo (cost=0.00..12.50 rows=1000 width=4)

• 関数がデータをgatherするときに出てくる
• トラブルシューティングの観点からは若干ミステリアス
• 関数の中で使われているクエリについてexplainを走らせるべき

37


SetOp 演算子
=# EXPLAIN SELECT oid FROM pg_proc INTERSECT SELECT oid FROM pg_proc;
QUERY PLAN
------------------------------------------------------------------------
SetOp Intersect (cost=415.51..432.98 rows=349 width=4)
Sort Key: oid
-> Append (cost=0.00..209.88 rows=3494 width=4)
-> Subquery Scan "*SELECT* 1" (cost=0.00..104.94 rows=1747)
-> Seq Scan on pg_proc (cost=0.00..87.47 rows=1747)
-> Subquery Scan "*SELECT* 2" (cost=0.00..104.94 rows=1747)
-> Seq Scan on pg_proc (cost=0.00..87.47 rows=1747)

• INTERSECT, INTERSECT ALL, EXCEPT,
EXCEPT ALL句のために使用される
– SetOp Intersect, Intersect All, Except, Except All
38

INTERSECT, EXCEPT
• INTERSECT：両方の問い合わせ共通の行だけを返す。
A AND B
A B

• EXCEPT: 最初の結果集合にあり、
2番目の結果集合にない行だけを返す。
A-B
A B

• UNION: 両方の結果集合に存在する行と、
片方の結果集合に存在する行を返す。
A OR B
A B

39


実行プランの強制
• SET enable_演算子 = off;
– プランナーがある演算子を使おうとするのを「強く思いとどまらせる」
ことができる
– SETを行ったセッションのみに影響する
• Planner Method Configuration (on/off)
– enable_bitmapscan
– enable_hashagg
– enable_hashjoin
– enable_indexscan
– enable_mergejoin
– enable_nestloop
– enable_seqscan
– enable_sort
– enable_tidscan

40


Seq Scan の強制
=# EXPLAIN SELECT * FROM pg_class;
QUERY PLAN
-------------------------------------------------------
Seq Scan on pg_class
(cost=100000000.00..100000006.86 rows=186 width=164)

• 始動コストに 100000000.0 を足すだけ
– /src/backend/optimizer/path/costsize.c

41


スキャン強制, プランを変える
=# EXPLAIN ANALYZE SELECT * FROM pg_class WHERE oid > 2112;
QUERY PLAN
------------------------------------------------
Seq Scan on pg_class
(cost=0.00..7.33 rows=62 width=164)
Filter: (oid > 2112::oid)

=# SET enable_seqscan = off;
=# EXPLAIN ANALYZE SELECT * ORDER BY pg_class WHERE oid > 2112;
QUERY PLAN
------------------------------------------------
Index Scan using pg_class_oid_index on pg_class
(cost=0.00..22.84 rows=62 width=164)
Index Cond: (oid > 2112::oid)
Total runtime: 2.653 ms 42


心掛けるべきこと
• プランの強制は開発時にはよいが、製品には不適
– やむを得ず使う場合は SET LOCAL で設定すること。
トランザクショ完了時に元の設定に戻すように。

• （Tom Laneでもない限り）人はプランナーより賢くない
• 他方では、プランナーは推測しかしない
– 統計情報を正しい状態に保つため定期的なANALYZEを。
autovacuum に任せるのが一番確実。
– 環境に合わせてコスト変数 (Planner Cost Constants) を適
切に設定することが重要例えば random_page_cost （デフォルト=4）は
もっと小さくてもいいかも。。。

• 可能なときには、explain analyzeを使いなさい
43

参考文献
• 問合せ最適化インサイド
– 「とことんわかるPostgreSQLインサイド」講演資料。フォルシア板垣さん
– オプティマイザの動作について詳細解説。パクリ参考にしまくり。

• PostgreSQLソースコードの読み方～vi+ctags,gdb,strace～
– JPUGしくみ分科会第2回勉強会資料。NTTデータ先端技術井久保さん
– この資料でPostgreSQLのソースをデバッグできるようになりました。

• 内部を知って業務に活かす PostgreSQL研究所
第1回 PostgreSQLの構造と機能、第4回,第5回プラン処理
– WEB+DB PRESS連載。SRA OSS日本支社石井さん

• PostgreSQL完全機能リファレンス（書籍）
– InterDB 鈴木さん
44

JPUGしくみ＋アプリケーション勉強会（第20回）

More Related Content

What's hot (20)

Similar to JPUGしくみ＋アプリケーション勉強会（第20回） (20)

More from Yoshinori Nakanishi (6)

JPUGしくみ＋アプリケーション勉強会（第20回）