関西PostgreSQL勉強会2015/10/21実施分の資料です 実行計画の簡単なお話をさせていただきました。

1. 1
PostgreSQL 実行計画入門
2015/10/21
株式会社アシスト
山田 聡

2. 2
Who am I？
● 名前: 山田 聡
● 所属:株式会社アシスト
– サポートセンター
– PostgreSQL/PPAS/Oracle担当
● PostgreSQL歴 4年

3. 4
アジェンダ
● 実行計画って？
● PostgreSQLのプラン演算子
● 実行計画の作り方
● 実行計画の確認方法
● 実際に見てみよう！

4. 5
実行計画って？

5. 6
実行計画って？
実行計画
欲しいデータへの
道筋

6. 7
交通手段：プラン演算子
目的地：欲しいデータ
実行計画って？

7. 8
実際は複数の交通手段(プラン演算子)を
組み合わせて目的地(データ)へたどり着く
実行計画って？

8. 9
交通手段
交通手段
交通手段
旅行
交通手段
交通手段
プラン演算子
実行計画
実行計画って？

9. 10
PostgreSQLのプラン演算子

10. 11
PostgreSQLのプラン演算子
● 旅行で言う所の交通手段
● プラン演算子を組み合わせる
● 状況ごとに適した物を選ぶ必要がある

11. 12
PostgreSQLのプラン演算子
分類 演算子
表スキャン Seq Scan
Index Scan
Bitmap Index Scan
Bitmap Heap Scan
Index Only Scan
Subquery Scan
Tid Scan
その他 Function Scan
結合 Nested Loop
Merge Join
Hash Join
分類 演算子
検索結果への処理 Group
limit
Unique
Aggregate
Group Aggregate
Result
結果の結合 Append
SetOp
その他の処理補助 Sort

12. 13
PostgreSQLのプラン演算子
分類 演算子
表スキャン Seq Scan
Index Scan
Bitmap Index Scan
Bitmap Heap Scan
Index Only Scan
Subquery Scan
Tid Scan
その他 Function Scan
結合 Nested Loop
Merge Join
Hash Join
分類 演算子
検索結果への処理 Group
limit
Unique
Aggregate
Group Aggregate
Result
結果の結合 Append
SetOp
その他の処理補助 Sort
単一表用

13. 14
(1).SeqScan (2).Index Scan
0
0
0
0
1
(4).Index Only Scan
検索範囲：広 検索範囲：狭
1
0
1
0
0
(3).Bit Map Scan
検索範囲：中/特殊 検索範囲：特殊
PostgreSQLのプラン演算子

14. 15
・最も基本的なアクセス方法
・取り出す件数が多い時に有効
・表の最後までアクセスする
・シーケンシャルアクセス
(1).Seq Scan
検索範囲：広
PostgreSQLのプラン演算子
テーブル

15. 16
33
44
66
77
99
63
・取り出す件数が少ない時に有効
・インデックスとテーブルを
交互にアクセス
・ランダムアクセス
(2).Index Scan
検索範囲：狭
PostgreSQLのプラン演算子
テーブルインデックス

16. 17
1
0
1
0
0
8.1〜
・候補行をビットマップ化してアクセスする
・取り出す件数が中くらいの時に有効
・インデックスを使った結合も可能
Bit Map
インデックス
(3).Bit Map Scan
検索範囲：中/特殊
PostgreSQLのプラン演算子
テーブル

17. 18
0
0
0
0
1
・9.2からの新機能
・ほぼインデックスのみを検索
・Visibility Mapを併用
9.2〜(4).Index Only Scan
検索範囲：特殊
PostgreSQLのプラン演算子
インデックス Visibility Map

18. 19
PostgreSQLのプラン演算子
分類 演算子
表スキャン Seq Scan
Index Scan
Bitmap Index Scan
Bitmap Heap Scan
Index Only Scan
Subquery Scan
Tid Scan
その他 Function Scan
結合 Nested Loop
Merge Join
Hash Join
分類 演算子
検索結果への処理 Group
limit
Unique
Aggregate
Group Aggregate
Result
結果の結合 Append
SetOp
その他の処理補助 Sort
複数表の結合用

19. 20
(1).Nested Loop Join
88
22
77
55
11
55
88
22
66
99
外部表
88
22
77
55
11
55
88
22
66
99
1
2
5
7
8
2
5
6
8
9
55
88
22
11
77
88
22
77
55
11
内部表
外部表 内部表
外部表 内部表
(2).Merge Join
(3).Hash Join
特徴：いかなる場合でも
選択可能
特徴：ソートが完了すれば早い
特徴：ハッシュをオンメモリで
作成できればば早い
3つの結合方法
PostgreSQLのプラン演算子

20. 21
・最も基本的な結合方法
・ 外部表がの件数が少なく、
内部表にインデックスが
あることが望ましい。
・NとMが大きくなればなるほど
コストが膨らむ
外部表
outer table
内部表
inner table
特徴：いかなる場合でも
選択可能
PostgreSQLのプラン演算子
(1).Nested Loop Join

21. 22
PostgreSQLのプラン演算子
Nested Loop Join
● 少量データで最速
● データ見積もりを失敗すると最遅
● 速度の振れ幅が多い結合方法

22. 23
・ 結合前にソートすることで
結合処理を削減
・ ソートが出来れば早い。
(ソート済みのINDEXが
ある列との相性が良い)
88
22
77
55
11
55
88
22
66
99
1
2
5
7
8
2
5
6
8
9
外部表
outer table
内部表
inner table
特徴：ソートが完了すれば早い
PostgreSQLのプラン演算子
(2).Merge Join

23. 24
PostgreSQLのプラン演算子
Merge Join
● ソートが全て
● Indexがない結合でこれになるとTEMP大量

24. 25
・ 内部表をベースにメモリ上に
ハッシュ表を作り外部表は
これにアクセスし 結合する
・ ハッシュ表を作ってしまえば
その後の計算は早い。
外部表
outer table
内部表
inner tableハッシュ表
55
88
22
11
77
88
22
77
55
11
特徴：ハッシュをオンメモリで
作成できればば早い
PostgreSQLのプラン演算子
(3).Hash Join

25. 26
PostgreSQLのプラン演算子
Hash Join
● WORK_MEMさえ余裕があれば安定
● データ量でのパフォーマンス幅が狭い

26. 27
PostgreSQLのプラン演算子
● PostgreSQLの演算子は豊富
● MySQLの結合はNested Loopしかない
最適なプラン演算子の
組み合わせを求める事が重要

27. 28
実行計画の作り方

28. 29
実行計画の作り方
SQL
そもそもSQL実行フローって
パーサ
アナライザ
リライタ
プランナ
エグゼキュータ 結果

29. 30
実行計画の作り方
SQL
そもそもSQL実行フローって
パーサ
アナライザ
リライタ
プランナ
エグゼキュータ 結果
構文解析
SQL書換
実行計画作成
表存在チェック

30. 31
実行計画の作り方
SQL
そもそもSQL実行フローって
パーサ
アナライザ
リライタ
プランナ
エグゼキュータ 結果
実行計画作成
※他のステップなどは過去の
PostgreSQL勉強会の資料をご覧下さい
http://www.slideshare.net/MikiShimogai/postgre-sql-explain

31. 32
● プランナが統計情報を元に作る
● 統計情報は行数や値の偏り
● 複数の実行計画を候補として作る
● その中でコストが最も低いものを使う
実行計画の作り方

32. 33
● プランナが統計情報を元に作る
● 統計情報は行数や値の偏り
● 複数の実行計画を候補として作る
● その中でコストが最も低いものを使う
実行計画の作り方
コスト単位 = シーケンシャルで
1ブロック読み込みとの相対値

33. 34
● 統計情報の取得方法
– ANALYZE <table_name>;
– autovacuum でも取得される
● pg_statsでどんな値が取られたか確認可能
● 統計情報は取得時点のオブジェクトの状態
実行計画の作り方

34. 35
実行計画の作り方
sampledb=# select * from pg_stats where tablename='emp' and attname='job';
-[ RECORD 1 ]----------+--------------------------------------
schemaname | public
tablename | emp
attname | job
inherited | f
null_frac | 0
avg_width | 7
n_distinct | -0.357143
most_common_vals | {CLERK,SALESMAN,MANAGER,ANALYST}
most_common_freqs | {0.285714,0.285714,0.214286,0.142857}
histogram_bounds |
correlation | -0.30989
most_common_elems |
most_common_elem_freqs |
elem_count_histogram |
pg_statsの例

35. 36
実行計画の作り方
古い統計情報 プランナー
(だいたい)
Badな
実行計画
EMP表
(14行)
EMP表
(1億行)
1億行追加 SELECT
プランナは14行
として実行計画作成
SeqScanして
死ぬ
ここでANALYZE
→14行で認識

36. 37
実行計画の作り方
最新の統計情報 プランナー
(だいたい)
Goodな
実行計画
EMP表
(14行)
ここでANALYZE
→14行で認識
EMP表
(1億行)
1億行追加 SELECT
もう一度ANALYZE
→1億行で認識
IndexScanで
幸せ

37. 38
実行計画の確認方法

38. 39
● 確認はEXPLAINコマンドを使用
● EXPLAIN <対象のSQL>; で利用可能
実行計画の確認方法
プランナの気持ちを
可視化するコマンド

39. 40
実行計画の確認方法
EXPLAIN select ename, dname from
emp e,dept d where e.deptno=d.deptno;
Hash Join (cost=1.09..2.42 rows=14 width=15)
Hash Cond: (e.deptno = d.deptno)
-> Seq Scan on emp e (cost=0.00..1.14 rows=14 width=11)
-> Hash (cost=1.04..1.04 rows=4 width=14)
-> Seq Scan on dept d (cost=0.00..1.04 rows=4 width=14)

40. 41
実行計画の確認方法
EXPLAIN select ename, dname from
emp e,dept d where e.deptno=d.deptno;
Hash Join (cost=1.09..2.42 rows=14 width=15)
Hash Cond: (e.deptno = d.deptno)
-> Seq Scan on emp e (cost=0.00..1.14 rows=14 width=11)
-> Hash (cost=1.04..1.04 rows=4 width=14)
-> Seq Scan on dept d (cost=0.00..1.04 rows=4 width=14)①
③
②
④

41. 42
● -> の部分が1ステップ
● インデントが深い所から先に実行
● インデントが同じなら上が先
実行計画の確認方法

42. 43
実行計画の確認方法
Seq Scan on dept d
Hash Join (cost=1.09..2.42 rows=14 width=15)
Hash Cond: (e.deptno = d.deptno)
-> Seq Scan on emp e (cost=0.00..1.14 rows=14 width=11)
-> Hash (cost=1.04..1.04 rows=4 width=14)
-> Seq Scan on dept d (cost=0.00..1.04 rows=4 width=14)
Hash Seq Scan on emp e
Hash Join

43. 44
実行計画の確認方法
EXPLAIN select ename, dname from
emp e,dept d where e.deptno=d.deptno;
Hash Join (cost=1.09..2.42 rows=14 width=15)
Hash Cond: (e.deptno = d.deptno)
-> Seq Scan on emp e (cost=0.00..1.14 rows=14 width=11)
-> Hash (cost=1.04..1.04 rows=4 width=14)
-> Seq Scan on dept d (cost=0.00..1.04 rows=4 width=14)

44. 45
実行計画の確認方法
Hash Join (cost=1.09..2.42 rows=14 width=15)
見積りコスト
(始動コスト..総コスト)
見積り行数
見積り平均行長

45. 46
実行計画の確認方法
Hash Join (cost=1.09..2.42 rows=14 width=15)
見積りコスト
(始動コスト..総コスト)
見積り行数
見積り平均行長
大体総コストと行数を見ます

46. 47
● EXPLAINの結果は統計情報からの見積り
– コストが低いからといって最適なプランとは限らない
– 統計情報が古いと誤った値になり得る
● 実際のデータからの情報をみるには
ANALYZEオプションを追加
– 実際にSQLを発行して情報収集
– 負荷に注意!!
実行計画の確認方法

47. 48
SQL
パーサ
アナライザ
リライタ
プランナ
エグゼキュータ 結果
EXPLAIN
EXPLAIN ANALYZE
実行計画の確認方法

48. 49
実行計画の確認方法
EXPLAIN ANALYZE select ename, dname from
emp e,dept d where e.deptno=d.deptno;
Hash Join (cost=1.09..2.42 rows=14 width=15)
(actual time=11.835..11.868 rows=14 loops=1)
Hash Cond: (e.deptno = d.deptno)
-> Seq Scan on emp e (cost=0.00..1.14 rows=14 width=11)
(actual time=11.714..11.723 rows=14 loops=1)
-> Hash (cost=1.04..1.04 rows=4 width=14)
(actual time=0.037..0.037 rows=4 loops=1)
Buckets: 1024 Batches: 1 Memory Usage: 1kB
-> Seq Scan on dept d (cost=0.00..1.04 rows=4 width=14)
(actual time=0.018..0.021 rows=4 loops=1)
Total runtime: 11.950 ms

49. 50
実行計画の確認方法
EXPLAIN ANALYZE select ename, dname from
emp e,dept d where e.deptno=d.deptno;
Hash Join (cost=1.09..2.42 rows=14 width=15)
(actual time=11.835..11.868 rows=14 loops=1)
Hash Cond: (e.deptno = d.deptno)
-> Seq Scan on emp e (cost=0.00..1.14 rows=14 width=11)
(actual time=11.714..11.723 rows=14 loops=1)
-> Hash (cost=1.04..1.04 rows=4 width=14)
(actual time=0.037..0.037 rows=4 loops=1)
Buckets: 1024 Batches: 1 Memory Usage: 1kB
-> Seq Scan on dept d (cost=0.00..1.04 rows=4 width=14)
(actual time=0.018..0.021 rows=4 loops=1)
Total runtime: 11.950 ms

50. 51
実行計画の確認方法
Hash Join (cost=1.09..2.42 rows=14 width=15)
(actual time=11.835..11.868 rows=14 loops=1)
処理時間
(1行目の時間..最終行の時間)
実際に戻った行数
ステップの実行回数
(Nested Loop等)

51. 52
実行計画の確認方法
Hash Join (cost=1.09..2.42 rows=14 width=15)
(actual time=11.835..11.868 rows=14 loops=1)
実際に戻った行数
見積り行数
この2つが違う場合は統計情報が
最新じゃないことが多い

52. 53
実行計画の確認方法
Hash Join (cost=1.09..2.42 rows=14 width=15)
(actual time=11.835..11.868 rows=14 loops=1)
Hash Cond: (e.deptno = d.deptno)
-> Seq Scan on emp e (cost=0.00..1.14 rows=14 width=11)
(actual time=11.714..11.723 rows=14 loops=1)
-> Hash (cost=1.04..1.04 rows=4 width=14)
(actual time=0.037..0.037 rows=4 loops=1)
Buckets: 1024 Batches: 1 Memory Usage: 1kB
-> Seq Scan on dept d (cost=0.00..1.04 rows=4 width=14)
(actual time=0.018..0.021 rows=4 loops=1)
※cost/actual timeは子要素の値を含んでいる

53. 54
● 2つのrowsがずれているところ
– 統計情報のズレを疑う
● actual timeが長い所
– ここを潰せると効果が大きい
– 子要素で見積りのずれが発生してないかチェック
● costが高い所
– 統計が最新ならcostが高い所への対処も検討
実行計画の確認方法
みるべきポイント

54. 55
実際に見てみよう！

55. 56
Hash Join
(cost=175782.31..405182.03 rows=53172 width=8)
(actual time=1834.952..1844.389 rows=9 loops=1)
Hash Cond: (exception.exception_id = exception_notice_map.exception_id)
-> Seq Scan on exception
(cost=0.00..144263.00 rows=5000000 width=4)
(actual time=789.879..790.120 rows=1000 loops=1)
Filter: (complete IS FALSE)
Rows Removed by Filter: 9999000
-> Hash
(cost=174037.01..174037.01 rows=106344 width=8)
(actual time=1044.821..1044.821 rows=100202 loops=1)
Buckets: 4096 Batches: 4 Memory Usage: 690kB
-> Seq Scan on exception_notice_map
(cost=0.00..174037.01 rows=106344 width=8)
(actual time=0.081..991.670 rows=100202 loops=1)
Filter: (notice_id = 3)
Rows Removed by Filter: 9900798
Total runtime: 1844.486 ms
実際に見てみよう！

56. 57
Hash Join
(cost=175782.31..405182.03 rows=53172 width=8)
(actual time=1834.952..1844.389 rows=9 loops=1)
Hash Cond: (exception.exception_id = exception_notice_map.exception_id)
-> Seq Scan on exception
(cost=0.00..144263.00 rows=5000000 width=4)
(actual time=789.879..790.120 rows=1000 loops=1)
Filter: (complete IS FALSE)
Rows Removed by Filter: 9999000
-> Hash
(cost=174037.01..174037.01 rows=106344 width=8)
(actual time=1044.821..1044.821 rows=100202 loops=1)
Buckets: 4096 Batches: 4 Memory Usage: 690kB
-> Seq Scan on exception_notice_map
(cost=0.00..174037.01 rows=106344 width=8)
(actual time=0.081..991.670 rows=100202 loops=1)
Filter: (notice_id = 3)
Rows Removed by Filter: 9900798
Total runtime: 1844.486 ms
実際に見てみよう！
このSQLは
4ステップ構成

57. 58
Hash Join
(cost=175782.31..405182.03 rows=53172 width=8)
(actual time=1834.952..1844.389 rows=9 loops=1)
Hash Cond: (exception.exception_id = exception_notice_map.exception_id)
-> Seq Scan on exception
(cost=0.00..144263.00 rows=5000000 width=4)
(actual time=789.879..790.120 rows=1000 loops=1)
Filter: (complete IS FALSE)
Rows Removed by Filter: 9999000
-> Hash
(cost=174037.01..174037.01 rows=106344 width=8)
(actual time=1044.821..1044.821 rows=100202 loops=1)
Buckets: 4096 Batches: 4 Memory Usage: 690kB
-> Seq Scan on exception_notice_map
(cost=0.00..174037.01 rows=106344 width=8)
(actual time=0.081..991.670 rows=100202 loops=1)
Filter: (notice_id = 3)
Rows Removed by Filter: 9900798
Total runtime: 1844.486 ms
実際に見てみよう！
見積りが
ずれている
こっちが先に
ずれている

58. 59
ANALYZEしてみる

59. 60
Nested Loop
(cost=0.43..152601.93 rows=11 width=8)
(actual time=792.030..794.257 rows=9 loops=1)
-> Seq Scan on exception
(cost=0.00..144262.43 rows=1000 width=4)
(actual time=790.677..790.885 rows=1000 loops=1)
Filter: (complete IS FALSE)
Rows Removed by Filter: 9999000
-> Index Scan using idx_nmap_exception_id on exception_notice_map
(cost=0.43..8.33 rows=1 width=8)
(actual time=0.003..0.003 rows=0 loops=1000)
Index Cond: (exception_id = exception.exception_id)
Filter: (notice_id = 3)
Rows Removed by Filter: 1
Total runtime: 817.182 ms
実際に見てみよう！
少数取り出しなので
NestedLoopに変更された

60. 61
まとめ

61. 62
● 実行計画はプラン演算子の集合
● プランナが自動で最適な構成を選んでくれる
– プランナのためにも統計情報を最新に！
● 確認にはEXPLAIN/EXPLAIN ANALYZE
● rowsやactual timeからあたりをつけてく
まとめ

62. 63
ご清聴
ありがとうございました

63. 64
● EXPLAINは初動調査ははほぼ同じ
● 実際は400行とかの実行計画を見る
– 人間が見るもんじゃない・・・
– 自動化したい
余談

64. 65
[
{
"Plan": {
"Node Type": "Hash Join",
"Join Type": "Inner",
"Startup Cost": 1.09,
"Total Cost": 2.42,
"Plan Rows": 14,
"Plan Width": 52,
"Actual Startup Time": 0.087,
"Actual Total Time": 0.121,
"Actual Rows": 14,
"Actual Loops": 1,
"Hash Cond": "(e.deptno = d.deptno)",
"Plans": [
{
"Node Type": "Seq Scan",
"Parent Relationship": "Outer",
"Relation Name": "emp",
:
● FORMAT JSON オプション
● psql -Atで無駄な出力削除
● JSONなので外部ツールと
連携可能
● どなたか作りませんか？