PostgreSQLの実行計画を読み解こう(OSC2015 Spring/Tokyo)
19 likes10,274 views
オープンソースカンファレンス2015 Spring/Tokyoでの 講演資料です。
More Related Content
What's hot (20)
Viewers also liked (13)
Similar to PostgreSQLの実行計画を読み解こう(OSC2015 Spring/Tokyo) (20)
More from Satoshi Yamada (13)
Recently uploaded (8)
PostgreSQLの実行計画を読み解こう(OSC2015 Spring/Tokyo)
- 1. 1 やまそふと PostgreSQLの実行計画を読み解こう -PostgreSQL SQLチューニング入門- オープソース カンファレンス 2015 Tokyo/Spring 株式会社アシスト 山田 聡
- 2. 2 Who am I ? 名前:山田 聡(やまだ さとし) 会社:株式会社アシスト 仕事:PostgreSQL+PPASのサポート (●racleも...) PostgreSQL歴:4年
- 5. 5 アジェンダ 1.実行計画って何？ 2.プラン演算子にはどんなものがあるの？ 3.どうやって実行計画を作ってるの？ 4.切り札！Explain Plan 5.問題を解決してみよう！ 6.まとめ
- 12. 12 2.プラン演算子にはどんなものがあるの？ 分類 演算子 表スキャン 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 PostgreSQLの演算子は様々
- 13. 13 2.プラン演算子にはどんなものがあるの？ (1).Seq Scan (2).Index Scan 0 0 0 0 1 (4).Index Only Scan 検索範囲：広 検索範囲：狭 1 0 1 0 0 (3).Bit Map Scan 検索範囲：中/特殊 検索範囲：特殊
- 16. 17 2.プラン演算子にはどんなものがあるの？ 1 0 1 0 0 8.1〜 ・候補行をビットマップ化してアクセスする ・取り出す件数が中くらいの時に有効 ・インデックスを使った結合も可能 Bit Map インデックス 表 (3).Bit Map Scan 検索範囲：中/特殊
- 17. 18 2.プラン演算子にはどんなものがあるの？ 0 0 0 0 1 Visiblity Map ・9.2からの新機能 ・ほぼインデックスのみを検索 ・Visibility Mapを併用 インデックス 9.2〜(4).Index Only Scan 検索範囲：特殊
- 18. 19 2.プラン演算子にはどんなものがあるの？ (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つの結合方法
- 19. 20 2.プラン演算子にはどんなものがあるの？ (1).Nested Loop Join ・最も基本的な結合方法 ・ 外部表がの件数が少なく、 内部表にインデックスが あることが望ましい。 ・NとMが大きくなればなるほど コストが膨らむ 外部表 outer table 内部表 inner table 特徴：いかなる場合でも 選択可能
- 20. 21 2.プラン演算子にはどんなものがあるの？ ・ 結合前にソートすることで 結合処理を削減 ・ ソートが出来れば早い。 (ソート済みの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 (2).Merge Join 特徴：ソートが完了すれば早い
- 21. 22 2.プラン演算子にはどんなものがあるの？ ・ 内部表をベースにメモリ上に ハッシュ表を作り外部表は これにアクセスし結合する ・ ハッシュ表を作ってしまえば その後の計算は早い。 外部表 outer table 内部表 inner tableハッシュ表 55 88 22 11 77 88 22 77 55 11 (3).Hash Join 特徴：ハッシュをオンメモリで 作成できればば早い
- 25. 26 3.どうやって実行計画を作ってるの？ 統計情報は事前に収集した情報 表の行数 行サイズの平均 相関 値の分布(ヒストグラム) 等 ANALYZE 表名; で取得 autovacuumでも取得
- 29. 30 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) キーワード 意味 cost 見積もりコスト rows 見積もり行数 width 見積もり平均長 始動コスト..総コスト ※基本的に総コストを見れば良い EXPLAIN
- 30. 31 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 キーワード 意味 actual time 実際にかかった時間 rows 実際の行数 loops ステップの繰り返し数 EXPLAIN ANALYZE 1行の時間..最終行の時間 ※基本的に最終行の時間を見れば良い
- 33. 34 EXPLAIN ANALYZE SELECT e.empno,d.dname,s.grade FROM emp e JOIN dept d ON e.deptno=d.deptno JOIN salgrade s on e.sal between s.losal and s.hisal where e.job='SALESMAN'; Column | Type ----------+----------------------------- empno | integer ename | character varying(10) job | character varying(9) mgr | integer hiredate | timestamp without time zone sal | integer comm | integer deptno | integer EMP表 Column | Type --------+----------------------- deptno | integer dname | character varying(14) loc | character varying(13) DEPT表 Column | Type --------+--------- grade | integer losal | integer hisal | integer SALGRADE表 4.切り札！EXPLAIN
- 34. 35 Nested Loop (cost=0.00..7.85 rows=1 width=50) (actual time=0.031..0.089 rows=4 loops=1) Join Filter: ((emp.sal >= s.losal) AND (emp.sal <= s.hisal)) Rows Removed by Join Filter: 16 -> Nested Loop (cost=0.00..5.67 rows=1 width=54) (actual time=0.027..0.060 rows=4 loops=1) Join Filter: (emp.deptno = d.deptno) Rows Removed by Join Filter: 12 -> Seq Scan on emp (cost=0.00..1.18 rows=1 width=12) (actual time=0.014..0.020 rows=4 loops=1) Filter: ((job)::text = 'SALESMAN'::text) Rows Removed by Filter: 10 -> Seq Scan on dept d (cost=0.00..1.05 rows=4 width=50) (actual time=0.001..0.003 rows=4 loops=4) -> Seq Scan on salgrade s (cost=0.00..1.04 rows=5 width=8) (actual time=0.001..0.002 rows=5 loops=4) ① ② ③ ④ ⑤ 4.切り札！EXPLAIN 出力結果
- 35. 36 実行結果をツリーにすると Seq Scan on emp cost=1.18 time=0.020 Seq Scan on dept d cost=1.05 time=0.003 x 4 Nested Loop cost=5.67 time=0.060 Seq Scan on salgrade s cost=1.04 time= 0.002 x 4 Nested Loop cost=7.85 time=0.089
- 38. 39 5.問題を解決してみよう！ Column | Type --------------+--------- exception_id | integer(primary key) complete | boolean EXCEPTION表 Column | Type -------------------------+--------- exception_notice_map_id | integer exception_id | integer notice_id | integer EXCEPTION_NOTICE_MAP表 complete 列の分布 TRUE FALSE Index Index ● indexは両表のexception_id列のみ作成 ● complete列はFalseのデータが1%未満 (1000行/10000000行)
- 39. 40 5.問題を解決してみよう！ EXPLAIN ANALYZE SELECT exception_id,exception_notice_map_id FROM exception JOIN exception_notice_map USING (exception_id) WHERE complete is false and notice_id=3; 実行するSQL
- 40. 41 5.問題を解決してみよう！ 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 結果
- 41. 42 – 最上位のノードはrows=9 →9行戻すSQL – 結合はHash Join – 処理時間は1844.486 ms(約2秒) もっと早くならないかな? 状況整理
- 42. 43 5.問題を解決してみよう！ 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 OK! OK! ずれてる！？ 見積との差をチェック
- 43. 44 5.問題を解決してみよう！ exception表でcompelete is Falseの行は 5000000行くらいかな 結合相手も行が多いしたくさん もどりそうだからHashJoinしよう (cost=0.00..144263.00 rows=5000000 width=4) (actual time=789.879..790.120 rows=1000 loops=1) 1000行しかなかった… プランナー プランナー
- 45. 46 5.問題を解決してみよう！ 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 ずれがなくなった！！ 早くなった！ 1844.486 ms→817.182 ms ANALYZE後
- 47. 48 5.問題を解決してみよう！ 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 1%未満の行にSeq Scanで アクセスしている complete 列の分布 TRUE FALSE 再度結果を確認
- 49. 50 そうだ部分インデックスがあるじゃないか！ CREATE INDEX idx_is_complete ON exception(complete) WHERE complete IS false;
- 51. 52 5.問題を解決してみよう！ 部分INDEX作ったら... Nested Loop (cost=0.71..8347.79 rows=11 width=8) (actual time=0.266..5.241 rows=9 loops=1) -> Index Scan using idx_is_complete on exception (cost=0.28..8.29 rows=1000 width=4) (actual time=0.073..0.680 rows=1000 loops=1) Index Cond: (complete = false) -> Index Scan using idx_nmap_exception_id on exception_notice_map (cost=0.43..8.33 rows=1 width=8) (actual time=0.004..0.004 rows=0 loops=1000) Index Cond: (exception_id = exception.exception_id) Filter: (notice_id = 3) Rows Removed by Filter: 1 Total runtime: 5.286 ms Index Scanが使われるようになった！ 817.182 ms->5.286 ms 160倍早い！
- 53. 54 アジェンダ 1.実行計画って何？ 2.プラン演算子にはどんなものがあるの？ 3.どうやって実行計画を作ってるの？ 4.切り札！Explain Plan 5.問題を解決してみよう！ 6.まとめ
- 58. 59 6.まとめ (VACUUMとANALYZEを実行している前提) PostgreSQLのバージョンを書く EXPLAIN ANALYZEの結果を必ず書く クエリ、テーブル、データもできれば含める [email protected] (英語) [email protected] (日本語) メーリングリストに相談だ
- 59. 60 ご清聴ありがとうございました 参考資料(サイト) Explaining Explain ～ PostgreSQLの実行計画を読む ～ http://lets.postgresql.jp/documents/technical/query_tuning/explaining_explain_ja.pdf/view 内部を知って業務に活かす PostgreSQL研究所第4回 http://www2b.biglobe.ne.jp/~caco/webdb-pdfs/vol29.pdf Robert Haas blog http://rhaas.blogspot.com/2011/10/index-only-scans-weve-got-em.html 問合せ最適化インサイド http://www.slideshare.net/ItagakiTakahiro/ss-4656848 象と戯れ http://postgresql.g.hatena.ne.jp/umitanuki/20110425/1303752697 Explaining Explain 第2回 http://www.postgresql.jp/wg/shikumi/study20_materials Explaining Explain 第3回 http://www.postgresql.jp/wg/shikumi/study21_materials 参考資料(書籍) PostgreSQL 全機能バイブル(技術評論社) PostgreSQL 設計・運用計画の鉄則(技術評論社)