PostgreSQLSQLチューニング入門

入門編

PostgreSQLカンファレンス2014

2014年12月5日

TIS株式会社 下雅意美紀

1

自己紹介

• 氏名 下雅意美紀

• 所属 TIS株式会社

• 略歴 2014年：TIS株式会社に入社

• PostgreSQL歴 ＝ 入社歴

• 日頃のPostgreSQLとのふれあい

業務で日々勉強する以外にも、JPUGのしくみ分科会や(http://www.postgresql.jp/wg/shikumi/study30_materials)、PGEConsなど、PostgreSQLのコミュニティにも参加しています。

2

PostgreSQL SQLチューニング入門入門編

本セッションの目標

PostgreSQLがSQL実行時に内部でどのような処理を行っているかを知りましょう。

SQLチューニングで使用するExplainコマンドが出力する実行計画を読めるようになりましょう。

アジェンダ

・PostgreSQLのSQL実行の概要

・Explain実行結果(実行計画)の読み方

・Explain演算子の種類

3

SQLの実行

そもそもSQLはどのようにPostgreSQL内部で実行されているのか

4

PostgreSQLのSQL処理のフロー

DBにテーブルがあるか確認

SQLの書き換え

実行計画を実行

5

Explain

実行計画の表示

パーサ• SQL文の構文を解析して、文字列が正しい構文になっているかをチェック

• 構文が正しくなければエラーを返す

• 構文が正しければパースツリーの形に変換

• テーブル名やカラム名が実在するかは問わないので「ローパースツリー」とも呼ばれる

SELECT oid FROM pg_proc WHERE oid = 1;

SELECT

TargetList

oid

RelationList

pg_proc

Qualifier

Expression

=

1oid 6

PostgreSQLのSQL処理のフロー

DBにテーブルがあるか確認

SQLの書き換え

実行計画を実行

7

Explain

実行計画の表示

アナライザ• パースツリーをもとにどのような表や関数、演算子が参照されるかを判断して、クエリツリーを作成する

• この時DBにテーブルが存在するかチェックし、存在したらテーブル名をOIDに変換する

SELECT oid FROM pg_proc WHERE oid = 1;

SELECT

TargetList

oid

RelationList

pg_proc

Qualifier

Expression

=

1oid

カタログ

oidに変更 8

PostgreSQLのSQL処理のフロー

DBにテーブルがあるか確認

SQLの書き換え

実行計画を実行

9

Explain

実行計画の表示

リライタ

• PostgreSQLではVIEWやRULEはSQL文を書き換えることで実行している

• このような書き換えの処理をリライタという

10

PostgreSQLのSQL処理のフロー

DBにテーブルがあるか確認

SQLの書き換え

実行計画を実行

11

Explain

実行計画の表示

プランナ• クエリツリーを解析して、最も効率的にSQLを実行するためのデータへのアクセス方法(アクセスパス)や結合などの処理を求める

• 処理の種類によりアクセスパスの種類がある

• アクセスパスが単位となり、データ取得までのコストが計算される

• 実行計画はコストが最小のものが選ばれる(問い合わせの最適化)

• ここでの実行計画のコストはあくまで推定値

クエリツリー

パス単位でコスト計算

最小コストのものを実行計画に

アクセスパスの種類・テーブル全件スキャン

・テーブルをインデックスを使ってスキャン・テーブル結合・関数を実行するなどなど、、、

12

ということで、実行計画とは、・実行計画とは、問い合わせを実行するときに、

• どの方式でテーブルを検索するか

• 複数のテーブルがある時はどの順序や結合方式で検索するか

などを記述したもの

・どのような実行計画が選ばれるかはコストで決まる

・Explainはこの実行計画を表示するコマンド

13

PostgreSQLのSQL処理のフロー

DBにテーブルがあるか確認

SQLの書き換え

実行計画を実行

14

Explain

実行計画の表示

エグゼキュータ

• プランナで作成した実行計画を実際に実行する

• 方式によって実行ルーチンが変わる

表スキャン

結合処理

条件処理

15

ということで、

16

SQLの実行を端的に言うと• PostgreSQLはSQL文を実行する際にSQL文を分解して、最も効率の良い実行計画でデータを取得しようとする

• PostgreSQLは実行計画を推定してくれる

• そのPostgreSQLによって推定された実行計画の詳細を表示

してくれるのがExplainです。

17

Explain

SQL実行のための実行計画

なぜExplainしなければならないのか• SQL文をより高速に実行し、DBのパフォーマンスを上げるには(SQLチューニングするには)、SQL文の構造とSQL文に含まれるデータの性質にとって最適なプラン(実行計画)を持つことが重要

• しかしその最適なプランとPostgreSQLによって推定されたプランがいつも一致するとは限らない

• PostgreSQLによって推定されたプランが最適なプランかどうか確認するためにもExplainで確認することは大切

18

最適なプラン推定されたプラン ＝

Explainコマンドで確認しよう！

Explainの実行結果の読み方

19

Explain Planの例

=# EXPLAIN SELECT * FROM pg_procORDER BY proname;

QUERY PLAN----------------------------------------------------Sort (cost=181.55..185.92 rows=1747 width=322)

Sort Key: proname-> Seq Scan on pg_proc

(cost=0.00..87.47 rows=1747 width=322)

20

21

Explaining → Cost

• コストは、プランナがさまざまなプランの中からある特定のプランを選ぶための指標である

• 2つのコスト: 初期コスト (左) とトータルコスト (右)– 実行計画の比較で重要なのはトータルコスト。– いくつかの演算子には初期コストがある。無いものもある。– コストは推定値に過ぎない。その算出は結構複雑。

• 値はシーケンシャルI/Oで1ページを読み込むコストを 1.0 とした際の相対値で示される。

=# EXPLAIN SELECT oid FROM pg_proc;QUERY PLAN

------------------------------------------Seq Scan on pg_proc

(cost=0.00..87.47 rows=1747 width=4)

初期コストとトータルコスト

22

初期コスト 実行コスト

問い合わせに対して最後の行を返す

問い合わせに対して最初の行を返す

cost=0.00..87.47

トータルコスト

Explaining → Cost

パラメータ 説明 規定値 相対速度

seq_page_cost シーケンシャル読み込み1回 1.00 (基準)

random_page_cost ランダム読み込み1回 4.00 4倍遅い

cpu_tuple_cost 行の処理1回 0.01 100倍速い

cpu_index_tuple_cost 索引の処理1回 0.005 200倍速い

cpu_operator_cost 計算1回 0.0025 400倍速い

effective_cache_size ページキャッシュサイズ 128MB N/A

23

24

Explaining → Rows

• 推定された行数を表示する

• PostgreSQL 8.0以前では、一度もVACUUM/ANALYZEされていないテーブルについては1000行がデフォルト。

• 実際の値と大きくかけ離れている場合、vacuum あるいはanalyzeをすべきというサインである。

=# EXPLAIN SELECT oid FROM pg_proc;QUERY PLAN

------------------------------------------Seq Scan on pg_proc

(cost=0.00..87.47 rows=1747 width=4)

25

Explaining → Widths

• このレベルにおける推定された入力サイズを表示する。

• それほど重要ではない

=# EXPLAIN SELECT oid FROM pg_proc;QUERY PLAN

------------------------------------------Seq Scan on pg_proc

(cost=0.00..87.47 rows=1747 width=4)

smallint 2

integer 4

bigint 8

boolean 1

char(n) n+1

～

n+4

varchar(n)

text [ n文字 ]

一般的なデータ型のサイズについて

しかし、これらはみな推定された値である。

→実際のコストや行数を知るには？

26

27

Explaining → Explain Analyze

• 実際にSQLを実行し、実際の情報を表示する。• 時間はミリ秒で表示される。「コスト」とは無関係。• 全体の実行時間も表示される。• 「loops」は処理の繰り返し回数。実行時間(time)は繰り返し全体の時間を表す。

=# EXPLAIN ANALYZE SELECT oid FROM pg_proc;QUERY PLAN

------------------------------------------Seq Scan on pg_proc

(cost=0.00..87.47 rows=1747 width=4)(actual time=0.077..17.082 rows=1747 loops=1)

Total runtime: 20.125 ms

Explainの演算子

28

Explain演算子とは

• SQLを実行するための内部的な処理の計算タイプ

• 処理の内容に応じていくつかの種類がある

• PostgreSQLのプランナは、統計情報や作業領域(work_mem)の大きさなどをもとに、複数の演算子を組み合わせ、最も最適と推定される実行計画を選択する

• この演算子を変更して実行計画を変更するのがSQLチューニング

→演算子の処理について知っておくことが大切

29

主な演算子一覧分類 演算子 処理

テーブルスキャン Seq scan インデックスを使用せず、全件を検索

Index scan インデックスを使用してスキャン

Bitmap scan ビットマップを使用してスキャン

Index only scan 問い合わせがインデックスに含まれるカラムのみで完結する場合のスキャン

Tid scan 検索条件がタプルID(ctid)のスキャン

その他のスキャン Function scan 関数がデータをgatherした結果をスキャン

テーブルの結合 Nested Loop ネステッド・ループ結合を行う

Merge Join ソート・マージ結合を行う

Hash Join ハッシュ結合を行う

30

分類 演算子 処理

検索結果に対して作用

limit LIMIT,OFFSET

Unique UNIQUE

Aggregate 集計関数(count,sum,,,)

GroupAggregate

集計関数にGROUP BYを使用し、より大きな結果のセットを得る

Result 非テーブル問い合わせ

結果の結合 Append UNION(和)

SetOp INTERSECT(積),EXCEPT(差)

その他の処理を補助

Sort ソート処理

31

更に詳しく知りたい方はこちらをどうぞ→ 第20回目しくみ分科会 Explaing Explain第2回目http://www.postgresql.jp/wg/shikumi/sikumi_20/

テーブルスキャンする演算子

32

分類 演算子

テーブルスキャン Seq Scan

Index Scan

Bitmap Scan

Index Only Scan

Tid Scan

その他スキャン Function Scan

テーブルの結合 Nested Loop

Merge Join

Hash Join

分類 演算子

検索結果に対して作用

limit

Unique

Aggregate

Group Aggregate

Result

結果の結合 Append

SetOp

その他の処理を補助

Sort

33

Seq Scan 演算子

• 最も基本。単に表を最初から最後へとスキャンする

• 条件にかかわらず各行をチェックする

• 大きなテーブルはインデックススキャンの方が良い

• コスト(開始コスト無し), 行(タプル), 幅(oid)

• トータルコストは92.12

=# EXPLAIN SELECT oid FROM pg_proc WHERE oid = 1;QUERY PLAN

--------------------------------------------------Seq Scan on pg_proc(cost=0.00..92.12 rows=1 width=4)Filter: (oid = 1::oid)

34

Seq Scan について• テーブルを最初から最後までチェックして必要な行を探す。

• 検索条件に合致するインデックスがない場合はこれしかない。

• インデックスが使えても対象行が多い場合は Seq Scan に。

⇒プランナがコスト計算した結果を比較して判断する。

id = 1

id = 11

id = 34

id = 45

・・・

テーブルid列のインデックス

使わない

先頭行から順に走査（最後の行まで見る必要あり）

Seq Scan のコスト= DISK I/O コスト + CPU コスト= テーブル全ページ数×sequential_page_cost

+ テーブル全行数×cpu_tuple_cost+ テーブル全行数×cpu_operator_cost

・ テーブル全ページ数 pg_class の relpages・ テーブル全行数 pg_calss の reltuples・ シーケンシャルにDISK1ページを読むコスト

sequential_page_cost = 1・ 1行を走査するCPUコスト

cpu_tuple_cost = 0.01・ 計算1回のCPUコスト (条件絞りこみ)

cpu_operator_cost = 0.0025

Seq Scanのコスト計算Seq Scanのコスト = (DISK I/Oコスト)＋(CPUコスト)

＝(テーブル全ページ数×Seq_page_cost)

＋(テーブル全行数× cpu_tuple_cost )

＋(テーブル全行数×cpu_operator_cost)

35

=# SELECT relpages,reltuples FROM pg_classWHERE relname = 'pg_proc';

relpages | reltuples----------+-----------

61 | 2490

=# EXPLAIN SELECT oid FROM pg_proc WHERE oid = 1;QUERY PLAN

--------------------------------------------------Seq Scan on pg_proc(cost=0.00..92.12 rows=1 width=4)Filter: (oid = 1::oid)

総コスト= (61×1.0) + (2490×0.01)

+ (2490×0.0025) = 92.125

テーブル全ページ数

テーブル全行数

規定値 0.0025

36

Index Scan 演算子

• 特に大きなテーブルではコストが低くなるので選ばれる可能性が高い

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

=# 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)

37

Index Scan について• 検索条件に合致するインデックスがあれば検討する。

• 通常は対象行が少なければこちらが選択される。

• インデックスとテーブルを交互にアクセスする。

id = 1

id = 11

id = 34

id = 45

・・・

１ １１ 45 100

テーブルid列のインデックス

検索条件に合うリーフノードを探索

必要な行にランダムアクセス

Index Scan のコスト= インデックスI/Oコスト + テーブルI/Oコスト+ インデックスCPUコスト + テーブルCPUコスト

インデックスI/Oコスト= 必要ページ数×sequential_page_cost（1）

テーブルI/Oコスト= 必要行数×(1～4) ※

インデックスCPUコスト= 必要行数×cpu_index_tuple_cost（0.005）

テーブルCPUコスト= 必要行数×cpu_tuple_cost（0.01）

※アクセスページがメモリサイズ(effective_cache_size)の何倍かでアクセスコストは変化

38

必要行数って何？

• 指定条件を満たす行数

• Explain の実行結果で 「rows=100」 とか表示される値。

• プランナがテーブルの統計情報から行数を予測。

⇒実際に検索した時の行数とは異なる。

• 必要行数 = 選択度×テーブル行数

• 「選択度」は対象データがカラムに存在する割合

• 選択度は対象カラムの統計情報を使って計算

• 各カラム値の分布は pg_stats（pg_statistic）でわかる。

⇒ ANALYZE時に収集した情報が格納されている。

39

Bitmap Scan 演算子

• 8.1で追加された

• BitmapOr, BitmapAndで複数のビットマップを合体

• リレーションの”ビットマップ“をメモリ内で作成する

40

Bitmap Scan について• インデックスを有効に使って検索効率を向上させる機構

• ORで結合した条件式を使った検索に効果大

id1 = 1, id2 = 33

id1 = 11, id2 = 55

id1 = 34, id2 = 77

id1 = 45, id2 = 99

・・・

１ １１ 34 45

テーブル

id1列のインデックス

ビットONの行を取得

33 55 77 99

id2列のインデックス

WHERE (id1 BETWEEN 10 AND 40) OR (id2 BETWEEN 20 AND 70)

0

1

1

0

・・

1

1

0

0

・・

Bitmap Index Scan

1

1

1

0

・・

BitmapOr

条件を満たす行（TID）をビットマップとして生成

ビットマップ同士でOR演算

Bitmap Heap Scan

同一ページ内に複数の対象行がある場合、まとめて取得できるので、I/Oコストが有利になる。

Index Only Scan

• 9.2で追加された

• 取得したい値にインデックスが含まれるとき、テーブルのアクセスを省略して検索する

• 非常に高速(しかしindex only scanが選ばれるには条件が…)

41

Index Only Scanのスキャン方法

• Index Only ScanはまずインデックスからVisibility Mapを参照しに行く(早速テーブルには行かない)

• そして高速に値を返せるか返せないかは、実はこのVisibility Mapにかかっている

→このVisibility Mapって一体何者なの？

42

Visibility Mapとは• ページ内にトランザクションによって更新され、参照することができなくなったタプルがあるかどうかを、ビットで管理している

• テーブルのブロック毎に1bitのデータ領域を確保し、不要なタプルがない&&どのトランザクションも更新していないブロックには”0”を、それ以外は”1”を保存する

43

ブロック1の可視性

ブロック2の可視性

ブロック1

ブロック2

ブロック3

ブロック4

Visibility Mapのbitが0だと• テーブルにアクセスすることなくタプルの値を返す

44

…

ブロック

1

2

3

4

全タプル有効!

１ １１ 34 45

インデックス

SELECT id FROM table1 WHERE id BETWEEN 1 AND 11

テーブル

テーブルにアクセスしない

Visibility Mapのbitが1だと• タプルの値が返せるものか判断するために通常のテーブルアクセスを行う

45

無効タプルあり！

…

ブロック

1

2

3

4１ １１ 34 45

インデックス

SELECT id FROM table1 WHERE id BETWEEN 1 AND 11

テーブル

1

本当に値返していいの？テーブルにアクセスしよう

不要タプルの回収・トランザクションによって発生した不要タプルを回収するにはvacuumを行う

無効タプル

46

ブロック2ViisibilityMap

ブロック2

ブロック1

ブロック3

ブロック4

ブロック5

テーブルVACUUM前

VACUUM後

再利用可能タプル

ブロック2ViisibilityMap

ブロック2

ブロック1

ブロック3

ブロック4

ブロック5

テーブル

47

Tid Scan 演算子

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

=# 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)

処理を補助する演算子

48

分類 演算子

テーブルスキャン Seq Scan

Index Scan

Bitmap Scan

Index Only Scan

Tid Scan

その他スキャン Function Scan

テーブルの結合 Nested Loop

Merge Join

Hash Join

分類 演算子

検索結果に対して作用

limit

Unique

Aggregate

Group Aggregate

Result

結果の結合 Append

SetOp

その他の処理を補助

Sort

49

Sort 演算子

• 明示的なソート : ORDER BY句

• 暗黙的なソート : Unique, Sort-Merge Join など

• 開始コストを持っている: 最初の値はすぐには返却されない

=# EXPLAIN SELECT oid FROM pg_proc ORDER BY oid;QUERY PLAN

---------------------------------------------Sort (cost=181.55..185.92 rows=1747 width=4)

Sort Key: oid-> Seq Scan on pg_proc

(cost=0.00..87.47 rows=1747 width=4)

50

Sort について• データが作業メモリ（work_mem）に収まればクイックソート

– DISK I/Oが発生しない。高速。

• 作業メモリに収まらなければ外部ソートを選択

– アルゴリズムは「マージソート」

– DISK I/Oが発生するのでクイックソートより低速。

– I/Oコストは対象データと work_memのサイズで変わってくる。

work_memに収まるサイズ毎にソートを繰り返すから。多分。。。

– 詳しくは /src/backend/optimizer/path/costsize.cの cost_sort参照。

7

4

9

2

DISK

•対象データを全てメモリに保持

• メモリ上でクイックソートを実行

7

4

9

2

2

4

7

9

2

4

7

9

8

1

3

5

1

3

5

8

DISK DISK

・・・

【対象データ < work_mem】

work_mem

【対象データ > work_mem】

work_mem 以下を繰り返す。•データの一部をメモリに保持

• メモリ上でソート実行•ソート結果を

DISKに戻す

51

Sortの実行例# EXPLAIN ANALYZE SELECT * FROM pgbench_accounts ORDER BY bid;--------------------------------------------------------------------------------------------------------------------------Sort (cost=290114.34..292614.34 rows=1000000 width=97)

(actual time=882.522..1186.626 rows=1000000 loops=1)Sort Key: bidSort Method: external sort Disk: 104600kB-> Seq Scan on pgbench_accounts (cost=0.00..26394.00 rows=1000000 width=97)

(actual time=0.023..176.540 rows=1000000 loops=1)Total runtime: 1264.377 ms

LOG: temporary file: path "base/pgsql_tmp/pgsql_tmp32001.0", size 107110400STATEMENT: EXPLAIN ANALYZE SELECT * FROM pgbench_accounts ORDER BY bid;

※ログに一時ファイル作成状況を表示（postgresql.conf の log_temp_files = 0）

メモリに収まったのでクイックソート

ソート対象が大きいので外部ソート

# SET work_mem=‘200MB’;# explain analyze select * from pgbench_accounts order by bid;--------------------------------------------------------------------------------------------------------------------------Sort (cost=126051.84..128551.84 rows=1000000 width=97)

(actual time=472.334..563.570 rows=1000000 loops=1)Sort Key: bidSort Method: quicksort Memory: 165202kB-> Seq Scan on pgbench_accounts (cost=0.00..26394.00 rows=1000000 width=97)

(actual time=0.030..166.788 rows=1000000 loops=1)Total runtime: 634.155 ms

※ work_mem を1⇒200MBに拡張して実行してみる

テーブル結合する演算子

52

分類 演算子

テーブルスキャン Seq Scan

Index Scan

Bitmap Scan

Index Only Scan

Tid Scan

その他スキャン Function Scan

テーブルの結合 Nested Loop

Merge Join

Hash Join

分類 演算子

検索結果に対して作用

limit

Unique

Aggregate

Group Aggregate

Result

結果の結合 Append

SetOp

その他の処理を補助

Sort

53

Nested Loop 演算子

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

=# EXPLAIN SELECT * FROM pgbench_accounts AS a,

pgbench_accounts AS b;

QUERY PLAN

---------------------------------------------------------------

Nested Loop

(cost=0.00..27637054248.00 rows=1000000000000 width=194)

-> Seq Scan on pgbench_accounts a

(cost=0.00..25874.00 rows=1000000 width=97)

-> Materialize (cost=0.00..46011.00 rows=1000000 width=97)

-> Seq Scan on pgbench_accounts b (cost=0.00..25874.00 rows=1000000 width=97)

Nested loop

・もっとも単純な結合方式

・外部テーブルを一レコードずつ取り出し、その都度内部テーブルの全レコードとマッチングする

・初期コストは0、総コストは結合するテーブルのレコード数の積に比する(O(M×N))

54

Merge Join 演算子# EXPLAIN SELECT * FROM pgbench_accounts AS a,

pgbench_tellers AS t where a.aid = t.tid;

QUERY PLAN

---------------------------------------------------------------

Merge Join (cost=5.94..11.25 rows=100 width=449)

Merge Cond: (a.aid = t.tid)

-> Index Scan using pgbench_accounts_pkey on pgbench_accounts a

(cost=0.42..39669.43 rows=1000000 width=97)

-> Sort (cost=5.32..5.57 rows=100 width=352)

Sort Key: t.tid

-> Seq Scan on pgbench_tellers t

(cost=0.00..2.00 rows=100 width=352)

• 二つのデータセットをJOINする：outerとinner• Merge Right JoinとMerge In Joinがある

• データセットはあらかじめソートされていなければならず、また両方同時に走査される。

55

56

Merge Join (ソートマージ)

• 事前に両方のテーブルを結合キーでソートする。

• 両方のテーブルを先頭からマッチングしていく。

⇒テーブルを1回調べればよく、テーブルの走査回数減

• 処理対象の行が多いケースで有効

2

4

7

9

2

7

4

9

2

1

4

3

外側テーブル（N件）

内側テーブル（M件）

結合キーで事前にソート

両テーブルをキー順にマッチング

1

2

3

4

結合キーで事前にソート

•ソートさえできれば速いが。。。

⇒インデックスがない列が結合キー

の場合はコスト大。

•計算量は O（NlogN + MlogM）。

57

Hash & Hash Join 演算子

• Hashは、異なる Hash Join演算子で使用されるハッシュテーブルを作成する

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

=# EXPLAIN SELECT * FROM pgbench_accounts AS a,

pgbench_tellers AS t where a.bid = t.bid;

QUERY PLAN

---------------------------------------------------------------

Hash Join (cost=3.25..140877.25 rows=10000000 width=449)

Hash Cond: (a.bid = t.bid)

-> Seq Scan on pgbench_accounts a

(cost=0.00..25874.00 rows=1000000 width=97)

-> Hash (cost=2.00..2.00 rows=100 width=352)

-> Seq Scan on pgbench_tellers t

(cost=0.00..2.00 rows=100 width=352)

58

Hash Join（ハッシュ値マッチング）

• 事前に内側テーブルのハッシュ表を作成。

⇒ハッシュ表を作成する初期コストが必要。• 外側テーブルとハッシュ表を突き合わせる。• ハッシュ表がメモリ(work_mem)に収まらないと性能劣化。

2

7

4

9

2

1

4

3

•一度ハッシュ表を作ってしまえば、

メモリ内で検索を行えるので

ハッシュ表の検索は高速。

•計算量のオーダーは O（N+M）。

外側テーブル（N件）

内側テーブル（M件）

ハッシュ表を事前に作成

ハッシュ表（メモリ内）

先頭から1行ずつスキャン

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

JOINの比較

• Nested loop joinは、データが小さい場合に向いている

• Merge joinは、データ量が多い場合に向いている

• Hash joinは、ソートメモリーが十分にある場合に向いている

59

検索結果に対して作用する演算子

60

分類 演算子

テーブルスキャン Seq Scan

Index Scan

Bitmap Scan

Index Only Scan

Tid Scan

その他スキャン Function Scan

テーブルの結合 Nested Loop

Merge Join

Hash Join

分類 演算子

検索結果に対して作用

limit

Unique

Aggregate

Group Aggregate

Result

結果の結合 Append

SetOp

その他の処理を補助

Sort

61

Limit 演算子

• 行は指定された数に等しい• 最初の行を即時に返す• 少量の開始コスト追加でオフセットの扱いも可

=# EXPLAIN SELECT oid FROM pg_proc LIMIT 5;QUERY PLAN

------------------------------------------Limit (cost=0.00..0.25 rows=5 width=4)

-> Seq Scan on pg_proc(cost=0.00..87.47 rows=1747 width=4)

=# EXPLAIN SELECT oid FROM pg_proc LIMIT 5 OFFSET 5;QUERY PLAN

------------------------------------------Limit (cost=0.25..0.50 rows=5 width=4)

-> Seq Scan on pg_proc(cost=0.00..87.47 rows=1747 width=4)

62

Unique 演算子

• 入力セットから重複する値を削除• 行の並べ替えはせず、単に重複する行を取り除く• 入力セットは予めソート済み (Sort演算子の後に行う)• タプルコストごとに「CPU演算」×2• DISTINCT と UNION で使用される

=# EXPLAIN SELECT distinct oid FROM pg_proc;QUERY PLAN

--------------------------------------------------Unique (cost=181.55..190.29 rows=1747 width=4)-> Sort (cost=181.55..185.92 rows=1747 width=4)

Sort Key: oid-> Seq Scan on pg_proc

(cost=0.00..87.47 rows=1747 width=4)

63

Aggregate 演算子

• count, sum, min, max, avg, stddev, varianceなどの集約関数を使用

=# 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)

64

GroupAggregate演算子

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

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

-----------------------------------------------------GroupAggregate (cost=0.28..108.15 rows=2529 width=4)

-> Index Only Scan using pg_proc_oid_index on pg_proc (cost=0.28..70.22 rows=2529 width=4)

65

Result 演算子

• 非テーブル問い合わせ

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

=# EXPLAIN SELECT 1 + 1 ;QUERY PLAN

------------------------------------------Result (cost=0.00..0.01 rows=1 width=0)

結果を結合する演算子

66

分類 演算子

テーブルスキャン Seq Scan

Index Scan

Bitmap Scan

Index Only Scan

Tid Scan

その他スキャン Function Scan

テーブルの結合 Nested Loop

Merge Join

Hash Join

分類 演算子

検索結果に対して作用

limit

Unique

Aggregate

Group Aggregate

Result

結果の結合 Append

SetOp

その他の処理を補助

Sort

67

Append 演算子

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

=# EXPLAIN SELECT oid FROM pg_procUNION ALL SELECT oid ORDER BY pg_proc;

QUERY PLAN--------------------------------------------------------------Append (cost=0.00..209.88 rows=3494 width=4)

-> Seq Scan on pg_proc (cost=0.00..87.47 rows=1747 width=4)-> Seq Scan on pg_proc (cost=0.00..87.47 rows=1747 width=4)

68

SetOp 演算子

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

=# 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 (cost=415.51..424.25 rows=3494 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)

Explainの演算子はこれら以外にも、

• SubqueryScan

• Material

：

などなどがあります。

そしてこれら演算子は、作業領域やインデックスの有無など様々な条件によって選択されます。

→実行計画内でなぜその演算子が選ばれたのか、どのような実行計画なのか中身を読み解くためにも、DBやインスタンスの状態には気をつけましょう。

69

次のセッションは、

お待ちかねの、

実行計画を実際に変更してDBのパフォーマンスアップを図る、SQLチューニング実践編です！

本セッションにて紹介した演算子がたくさんでてきますので、どうぞお楽しみにお待ちください！

70

参考文献• PostgreSQL全機能バイブル

鈴木啓修・著

• Explaining Explain ～ PostgreSQLの実行計画を読む～

by Robert Treat(翻訳：日本PostgreSQLユーザ会)

• Explaining EXPLAIN 第２回

第20回しくみ+アプリケーション勉強会中西さん

• Explaining Explain 第3回

第21回しくみ+アプリケーション勉強会 田中さん

• Let’s PostgreSQL

http://lets.postgresql.jp/

• PostgreSQL wiki

http://wiki.postgresql.org/wiki/Main_Page

• 問合わせ最適化インサイド

NTT オープンソースソフトウェアセンタ 板垣さん

71

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

72