問合せ最適化インサイド

PostgreSQL http://www.sigmodj.org/Events/tokoton-db0604.html 問合せ最適化インサイド NTT オープンソースソフトウェアセンタ板垣貴裕 2006.4.24 1

問合せ最適化インサイド：概要はじめに : 最適化とは？ Plannerインサイド Executor概要：何ができるのか？前処理：ルールベースで式を簡略化パス選択：コストベースでアクセスパスを列挙後処理：実行計画の生成最適化に必要な情報統計情報選択度まとめ 2

問合せ最適化とは？問合せが与えられた場合に、問合せ最も適切な実行計画を得ること最適化機構の入出力 Join 入力：問合せ構文解析済みのSQL（内部表現） Scan Scan どのような行が欲しいか？木構造の問合せ内部表現 “次の行が欲しい” 出力：実行計画実際の処理のパイプライン実行計画どうやって欲しい行を得るか？ 1行 3

例：テーブル2つの結合 Join SELECT * FROM A, B WHERE A.i = B.i AND i x i y A.x = 10 AND B.y < 100; テーブル A テーブル B 内部形式 Joinの方式 (= 条件を使う順序) Join クエリ A.i = B.i •A.xで絞込→対応するBを取得 A.x = 10 A.i = B.i B.y < 100 Scan on A Scan on B •B.yで絞込→対応するAを取得 A.x = 10 B.y < 100 B.y < 100 A.i = B.i A.x = 10 •A.x, B.yでそれぞれ絞込→結合 Scanの方式 A.x = 10 行へのアクセスパス A.i = B.i B.y < 100 •シーケンシャル読み取り •インデックス経由読み取り 4

“最適な”実行計画とは？クエリを処理する複数の方式複数の複数最適化の最適化の余地選ぶべき実行計画処理時間が最も短い実行計画処理時間代わりにルール / コストコストディスクアクセス (read, write, seek) CPU演算 (その他：通信時間, 並列度) PostgreSQLでは考慮の対象外 5

速度感と最適化の原則一般的な速度 (2006/4 現在) PostgreSQLは CPU (メモリ帯域) 1page = 8KB 6.4GB/s → 800,000 page/s ストレージのシーケンシャル読み込み (1台当り) 160MB/s → 20,000 page/s ストレージのランダム読み込み (1台当り) 100回/s → 100 page/s 最適化の原則処理の回数を減らす CPUを消費して、ストレージアクセスを減らすストレージはシーケンシャルに読み込む 6

Planner インサイド PostgreSQLの問合せ最適化機構 Executor概要ルールベースコストベース 7

Plannerとは？ PostgreSQLの問合せ最適化機構別名：オプティマイザ(optimizer) ソースコード：src/backend/optimizer 規模 Planner 関連 DBエンジン全体 45K行 420K行ストレージマネージャ関連 90K行個別型定義パーサとコマンド 110K行 60K行 8

Plannerの位置づけ SQL解析 SQL パース処理値の分布アナライズ処理 Parser 実データをリライト処理近似した情報内部問合せ問合せ Planner 統計情報最適化機構実行計画 Executor Storage 本講ではデータI/O Manager Black Box ストレージ結果アクセス 9

Plannerの内部処理の概要 Parser ルールベース式の書き換えに関するノウハウ前処理 (/prep) パス探索パス探索コストベースアクセスパス列挙 DP DP GEQO Planner 動的計画法 GEQO (/path) (/geqo) 遺伝的最適化後処理 (/plan) アクセスパス選択と実行計画の生成 Executor 10

Executor 概要 Parser Planner 統計情報 Executor 11

Executorとは？実際のデータ処理 Plannerが作成した実行計画に基づき、データを読み込み、処理するソースコード：src/backend/executor “次の行が欲しい” Executorの動作実行計画行をひとつずつ取り出す 1行内部的には粗粒度で処理する場合もあるシングルスレッド (8.1現在) Sort 実行計画はツリー構造 Join ツリーの各ノードが処理単位 Scan Scan 12

処理の種類 Scan：テーブルへのアクセス SeqScan ：シーケンシャル IndexScan ：インデックス経由 BitmapScan ：インデックスをビットマップ化 Join：2つのテーブルの結合 NestLoop ：入れ子ループ MergeJoin ：ソートマージ HashJoin ：ハッシュ値マッチングその他 Sort ：並び替え Hash ：ハッシュ化 Aggregate ：集約 13

Scan処理：テーブルへのアクセス SeqScan テーブルテーブル全体に対してシーケンシャルにアクセス候補行が多い場合に有効 IndexScan インデックスとテーブルをインデックス交互にアクセステーブル候補行が少ない場合に有効 3 4 ランダムアクセス BitmapScan 1 2 インデックスから得られた候補行をビットマップ化し、テーブルの候補行のみを取得インデックステーブル候補行が中程度の場合に有効 2 1 3 スキップしながら 0 シーケンシャルアクセス 0 4 1 1 複数のインデックスを併用可能ビットマップ 14

Join処理：2つのテーブルの結合 NestLoop 外内二重ループ外側1行ごとに内側ループを1週外側ループ回数が少ない場合に有効内側ループはIndexScanが望ましい外内 MergeJoin ソート済みの2つのテーブルを同時にスキャン双方の行数が多い場合に有効 B-treeインデックスがあると望ましい外内 HashJoin 内側ループのハッシュを作成外側ループの行と付き合わせるハッシュがメモリに収まる場合に有効ハッシュ 15

その他の処理 Sort メモリに収まる場合はクイックソート収まらない場合は外部ソート ORDER BY用 or MergeJoinの前処理 Hash ハッシュ関数によって型値を整数化ハッシュ関数 HashJoin, Aggregateの前処理 “文字列” 46 Aggregate (整数) 複数の行を1行に集約 Unique GROUP BY, DISTINCT 1 1 複数のアルゴリズム 1 2 HashAggregate (Hashを使用) 2 3 GroupAggregate (Sortを使用) 3 4 ソート済みの Unique (Sortを使用) 3 テーブルに対する 4 重複除去 16

Planner 前処理式の簡略化 Planner 式の事前評価前処理パス探索パス探索 DP GEQO 後処理 17

式の簡略化コストベース最適化の効率を高めるための式変形最適化の単位 = サブクエリ → サブクエリの個数を減らす Join SubQuery Scan Join Join Scan Scan Scan Scan Scan ルールベース = 開発者のノウハウの書き下し副問合せの引き上げ(pull-up) IN, ANY, サブクエリ, 明示的JOINなどを親クエリに一体化 OUTER JOIN を INNER JOIN に変換例：SELECT ... FROM A LEFT JOIN B ON (...) WHERE B.y = 42; 関数のインライン化関数内外を跨った最適化 (SQLで書かれた関数のみ) 18

例：明示的なJOINをFROM句に変換 SQL SELECT * FROM A, B WHERE A.i = B.i AND A.x = 10 AND B.y < 100; SELECT * FROM A JOIN B ON A.i = B.i WHERE A.x = 10 AND B.y < 100; SELECT * FROM A, (SELECT * FROM B WHERE y < 100) B WHERE A.i = B.i AND A.x = 10; Join A.i = B.i 最適化しやすい表現に変換 Scan on A Scan on B A.x = 10 B.y < 100 19

式の事前評価事前評価暗黙の条件の追加 / 冗長な条件の削除定数式(処理の間、結果が変わらない式)の最適化条件の追加と削除暗黙の条件の明示化例：A=B and B=C ⇒ A=C 冗長な条件の削除例：10 < x AND 20 < x ⇒ 20 < x 例：X OR TRUE ⇒ TRUE 定数式の最適化 Plannerの時点で先に結果を求めておく例：abs(-5) ⇒ 5 20

関数出力の安定性関数の出力の安定性は、関数ごとの属性に持つ CREATE FUNCTION name(…) [Immutable | Stable | Volatile] Immutable ある入力に対し、常に出力が一定数学系関数 +, -, *, /, abs() 文字列操作 || (連結), length(), position() Stable ある入力に対し、そのトランザクション内ならば出力が一定トランザクション開始時刻 now() 現在の状態 current_user() Volatile 実行するたびに出力が変化するシーケンス nextval() ランダム random() 現在時刻 timeofday() 21

Planner パス探索 Planner 前処理パス探索パス探索 DP GEQO 後処理 22

コストベースの最適化コストとは？ディスクアクセス時間共有バッファ状態は考慮しない常にディスクから読むことを仮定 CPU演算時間部分コスト初期コスト (startup cost) 最初の最初の行を取得するまでのコスト総合コスト (total cost) 最後の最後の行を取得するまでのコスト実行コスト (run cost) 総合コスト – 初期コスト：行取得中行取得中のコスト行取得中 23

部分コストと実質コスト処理する行の割合を考慮実質コスト = 初期コスト + 割合×実行コスト初期コスト実行コスト実際のコスト総合コスト最後の行の取得最初の行の取得割合の見積もり基本 : 100% 初期コスト ALL, ANY : 50% •ソート Cursor : 10% •ハッシュ作成 EXISTS : 1 / 行数 •BitmapScan初期化 LIMIT N : N / 行数 24

コスト計算に使用されるパラメータコスト名前説明 cost I/O (sequential_page_cost) シーケンシャル読込 (基準) 1 random_page_cost ランダム読込 4 CPU cpu_tuple_cost タプル処理 0.01 cpu_index_tuple_cost インデクスタプル処理 0.001 cpu_operator_cost 様々な計算処理 0.0025 メモリ work_mem 作業用バッファサイズ 1024KB effective_cache_size ページキャッシュ効果 1000 page 複雑な処理は cpu_operator_cost を基に計算ソート：2 * cpu_operator_cost * N logN (N : 行数) Bitmap同士の結合：100 * cpu_operator_cost 25

Scanのコストインデックステーブル SeqScan I/O – 全ページ数×S CPU – 全行数×T IndexScan I/O 必要ページ数×S 必要行数×RI CPU 必要行数×I 必要行数×T BitmapScan I/O 必要ページ数×S 必要ページ数×RB CPU (IndexScanと同じ) 初期コスト (他は実行コスト) S (sequential_page_cost) R random_page_cost 値の大小関係 T cpu_tuple_cost •全ページ数 > 必要行数 > 必要ページ数 I cpu_index_tuple_cost •R > { RI, RB } > S C cpu_operator_cost 26

RI : IndexScan時のディスク読み込みコスト random_ ページあたりのランダムアクセスコスト page_cost [default:4] 等量前後で急激に変化 ∞で random_page_cost と等しい 1 ランダムアクセスの遅さは (= sequential_ バッファキャッシュにより page_cost) 低減できることを表現 0 1 2 3 4 ランダムアクセスページ数/effective_cache_size (≒メモリの何倍のデータか) 27

RB : BitmapScan時のディスク読み込みコスト random_ ページあたりのランダムアクセスコスト page_cost [default:4] 少ないときは完全ランダムアクセス全件に近い場合は SeqScanと等しい 1 必要ページが運良く (= sequential_ 重なる or 並ぶとコストが page_cost) 減少することを表現 0 20 40 60 80 100 % 予想読み込みページ数/全ページ数 (≒全体のどれだけの割合を読み込むか) 28

Joinのコスト計算量 Join NestLoop : O(NM) Merge Join : O(NlogN+MlogM) Outer Inner Hash Join : O(N+M) N M コスト NestLoop 初期 Outer(初期) 実行 Outer(実行) + Outerの行数×Inner(総合) MergeJoin 初期 Outer(総合+Sort) + Inner(総合+Sort) 実行 CPUコストのみ HashJoin 初期 Inner(総合+Hash) + Outer(初期) 実行 Outer(実行) 29

作業用メモリ制限 work_mem 作業用メモリ領域サイズソート, ハッシュ, マテリアライズなどで使用自らメモリ消費量を管理 (OSではなく) 他のトランザクションに悪影響を与えないためソート方式の切り替えオンメモリ上ではクイックソートメモリが不足するとディスクを使った外部ソート外部ソートの場合はディスクアクセスコストを追加ハッシュ処理は外部化できないソートに切替 (HashAggregate → GroupAggregate) ソートを見かけたら、work_memを増やすと良い場合も 30

パス探索動的計画法 Planner 前処理パス探索パス探索 DP GEQO 後処理 31

動的計画法とは？仮定：最適経路中の部分経路もまた最適経路である経路ごとの最適な解以外は切り捨ててよい切異なる経路 JOINの順序結合は常に2つのテーブル間 (3つ以上の結合では複数の候補が存在) ソート状態どの列に対してソートされているか？後のソートで役に立つかもしれないため、記憶しておく同一の経路内での自由度 Scan方式 (SeqScan, IndexScan, BitmapScan) Join方式と方向 (NestLoop, MergeJoin, HashJoin) (重複除去するタイミング) PostgreSQLでは最適化しない 32

Joinの順番テーブル A 結合 AB テーブル B 結合 ABC SELECT * テーブル C FROM A, B, C WHERE テーブル A A.foo = B.foo テーブル B 結合 ABC AND 結合 BC B.bar = C.bar 2つずつテーブル C AND 結合 …; テーブル A 結合 CA テーブル B 結合 ABC テーブル C 33 関係の指定が無いため

Pathの列挙 A •SeqScan AB •IndexScan •NestLoop •BitmapScan •MergeJoin •HashJoin ABC B C Scan SeqScan 有用なインデックスを使ったIndexScan 有用なインデックスを組み合わせたBitmapScan Join NestLoop (内外入れ替え) MergeJoin (ソート済み or コスト最小+ソート) HashJoin (内外入れ替え) 34

パス探索遺伝的最適化 Planner 前処理パス探索パス探索 DP GEQO 後処理 35

遺伝的最適化(GEQO) 利点 Joinテーブル数が増えても最適化に必要な時間が短い動的計画法では O(N!) の時間がかかるあまり出番は多くない 12回以上のテーブルのJoinでのみ使用されるため比較的多くのJoinでも動的計画法で十分な速さデフォルト値はバージョンアップで変更されている 6.0以前 = GEQOなし 6.1- (1997/6) =6 6.3- (1998/3) =8 •CPUの高速化 6.5- (1999/6) = 11 •Plannerの改良 8.0- (2005/1) = 12 を反映 36

JOINテーブル数と計画生成時間 SELECT * FROM tbl t1, tbl t2, ... tbl tN; 100 動的計画法 10 DP 1 0 5 10 15 20 0.1 0.01 遺伝的最適化 0.001 GEQO 0.0001 geqo_threshold=12 環境 Pentium4 1.4GHz PostgreSQL8.1.3 37

後処理 Planner 前処理パス探索パス探索 DP GEQO 後処理 38

パスの選択と実行計画への変換パスの選択基本的には、実質コストが最小のものを選ぶただし、1%までのコスト差はランダム性あり実行計画への変換パラレルな構造 + 暗黙の処理の明示化 Pathをそのまま使わず、Planとしてコピーする Pathを含む最適化用の作業用メモリを一括解放 Path Plan Planでは Sort 明示化 Join Join Sort Hash Hash Group Scan Scan Scan Scan Limit 39

実行計画生成の仕上げ MIN/MAX用の特別な最適化 MIN/MAX を以下の形に置き換え ORDER BY column ASC/DESC LIMIT 1 集約関数にもかかわらずインデックスが使える集約関数は基本的にはインデックスを使わない (SUM, AVERAGE, …) 実行計画のトップノードとして追加 GROUP BY 用の集約ノード ORDER BY 用のソートノード DISTINCT 用の重複除去ノード (Sort + Unique) 40

まとめ：Planner Plannerの動作の流れ式を簡略化し、最適化しやすい式に変形アクセスパスを列挙し、コストを計算コストが最も低いパスを選択し、実行計画を作成 Plannerの最適化の方針 Planner 自分自身のトランザクションのみを考慮前処理他のプロセス状態は考慮しないデータがキャッシュ上にないことを仮定パス探索パス探索共有バッファ状態は考慮しないデータ書き出しは考慮しない DP GEQO 書き出しは別のプロセスが行う後処理 41

最適化に必要な情報統計情報選択度 42

値の内容による最適な実行計画の変化候補となる行数が変化すると、最適な実行計画が変わる場合がある例：SELECT * FROM A, B WHERE A.x = X AND B.y = Y AND A.id = B.id A.x = X の絞込みが強い絞込みの強さ NestLoop 外:A→内:B B.y = Y の絞込みが強い Join A.id = B.id NestLoop 外:B→内:A IndexScan + HashJoin Scan Scan SeqScan + HashJoin A.x = X B.y = Y IndexScan + MergeJoin 43

最適化のために必要な情報情報選択度 (Selectivity) 絞込みの強さ；ある条件を満たす行数統計情報 (Statistics) データ本体にアクセスしないまま、具体的なデータ値を考慮した最適化がしたい情報収集 ANALYZEコマンド保存先 pg_stat システムテーブル pg_statistic システムビュー 44

統計情報最適化に必要な情報統計情報選択度 45

ANALYZEコマンド：統計情報収集稼動状況統計とは ANALYZE table 直接関係なしページ数ページ数行数ヒストグラム (Compressed Histogram) Common値 (MCV: Most Common Values) 重複のある値を、重複数の多い順に並べたもの Uncommon値 (MCV以外) のヒストグラム各帯のサンプル数が均一化されるよう帯幅を調整 NULL率関係代数では X = Y と X IS NULL は別に扱われるためカーディナリティ (Cardinality) 濃度 or 値の種類(互いに異なる値の数) 相関値の大小とディスク上の順序の相関順序つきスキャンのコストに影響行サイズ平均ヒストグラム 46

Compressed Histogram 個数の多い値を分離したヒストグラムヒストグラムの精度を高めるため参考：ジップの法則 (Zipf’s Law) N番目に多い要素が全体に占める割合は1/Nに比例経験則 (値, 個数)のペアヒストグラム(大小順) で保持で保持 47

サンプリング数サンプリング係数(S) 範囲 : 1~1000 [default=10] 列ごとに指定可能テーブル中最も大きな係数を使用収集情報数 MCV = 10S MCV用作業領域 = 20S サンプリング行数 = 300S サンプリング数が足りない → 統計情報の精度が劣化特にカーディナリティの精度が劣化しやすいなぜか上限は1000 最大サンプリング数 300K行 10M行以上のテーブルだと1000でも不足？ 48

統計情報の保存先と稼働中の補正システムカタログ pg_class (テーブルのメタ情報) ページ数, 行数 pg_attribute (列のメタ情報) サンプリング数の係数 pg_statistic (テーブルの統計情報) NULL率, 平均行サイズ, カーディナリティ, ヒストグラム, 相関統計情報はANALYZE時にしか更新されない VACUUMと共に1日1回程度が推奨されている稼働中の変動に対する補正現在のファイルサイズ推定行数 = ANALYZE時の行数 × ANALYZE時のファイルサイズ 49

選択度最適化に必要な情報統計情報選択度 50

統計情報を使った選択度の算出一致検索：x = K 赤字統計情報 K ∈ Common値 MCVペアの値そのもの K ∈ Uncommon値行数 – NULL数数 MCVを除いた行数で計算カーディナリティ範囲検索：x < K Common値, Uncommon値を併せたヒストグラム K ヒストグラム 51

Joinの選択度：列1 = 列2 Common値, Uncommon値に分けてマッチング 1. 両辺のCommon値同士 2. 左辺の1でマッチしなかったCommon値と右辺のUncommon値 3. 2の辺を入れ替えたもの 4. 両辺のUncommon値同士左辺右辺 Common値 Common値 Uncommon値 Uncommon値 52

複数の選択条件の認識複数の選択条件独立とみなす Selectivity(A and B) = Selectivity(A) × Selectivity(B) 範囲選択条件 Selectivity(A < x < B) = Selectivity(A < x) + Selectivity(x < B) - 1 最小値 A<x x<B 最大値 53

統計情報を利用できない場合定数名値説明 DEFAULT_EQ_SEL 0.5% 等号 A = b DEFAULT_INEQ_SEL 33.3% 不等号 A < b DEFAULT_RANGE_INEQ_SEL 0.5% 範囲 b < A < c DEFAULT_MATCH_SEL 0.5% LIKE DEFAULT_UNK_SEL 0.5% IS NULL DEFAULT_NUM_DISTINCT 200 = 1/EQ_SEL (未知のテーブルの行数) ページ数/行サイズ or 1000 工夫されている点行/ページ = ~100 程度を仮定 EQ は 1%(ページごとひとつずつ)より低い RANGE (0.5%) ≠ INEQ2 (11.1%) 54

最適化のために必要な情報：まとめ動的な補正 SQL 一部処理にてストレージ情報へ Parser 直接アクセスデータ分布内部問合せ ANALYZEコマンドによるデータ値統計情報の取得 Planner 統計情報実行計画 Executor Storage Manager ANALYZEコマンド結果実際のデータから統計情報を計算 55

まとめ SQL Parser 前処理内部問合せパス探索パス探索 DP GEQO Planner 統計情報実行計画後処理 Executor Storage Manager 結果 56

まとめ Planner : PostgreSQLの問合せ最適化機構前処理：ルールベースの式の簡略化と事前評価パス探索：コスト計算とアクセスパスの列挙後処理：実行計画への変換最適化に必要な情報統計情報：データ分布のヒストグラム選択度：候補行数の推定 Plannerにうまく働いてもらうために… ANALYZEコマンドで統計情報を最新に保ちましょう EXPLAINコマンドで実行計画を確認しましょう 57

問合せ最適化インサイド Appendix 応用 Prepared Query テーブルパーティショニング Plannerへの不満重複除去が苦手問合せ最適化に対する拡張 OracleにあってPostgreSQLにないトラブルシュート EXPLAINコマンド例：SQLの書き方とインデックスの使用可否例：統計情報の精度不足 58

応用：Prepared Query 2系統のPrepared Query 最適化を最適化を行う場所簡易プロトコル：簡易プロトコル：PREPARE + EXECUTE プロトコル SQLのPREPARE, EXECUTEを使った場合 (名前付き) 引数：“変数”として実行計画を生成具体値ではないので、統計情報が使いづらい拡張プロトコル：拡張プロトコル：PARSE + BIND + EXECUTE プロトコル JDBCのPreparedStatementなどを使った場合 (無名) V3プロトコル (8.0以降) •libpq (C) 引数：“初回BIND時の定数”として実行計画を生成 •JDBC (java) 2回目以降のBINDでも初回の実行計画を使用 •PDO (php) 引数によって異なる実行計画を取るべき場合に不都合 •DBD (perl) 不満再最適化の指示ができない (8.1現在) 無名Prepared Queryはただ一つしか保持できないパース済み構文や実行計画を、複数プロセス間で共有できない JDBCのPreparedStatementオブジェクトをプールする旨みが無い 59

応用：テーブルパーティショニング Constraint Exclusion 制約を利用してより強い最適化を行う CHECK制約と問合せ条件を比較し、矛盾する表を除外例：レンジ・パーティショニング CREATE TABLE parent (key integer, ...); parent CREATE TABLE child1000 ( CHECK (key between 1000 and 1999) ) INHERITS (parent) ; child1000 CREATE TABLE child2000 ( CHECK (key between 2000 and 2999) ) INHERITS (parent) ; child2000 SELECT * FROM parent WHERE key = 2400; 不満検索を展開 “パーティショニング機能”としては使いづらい (UNION ALL) Oracle 7.3 (1996) のパーティションビューと同等 Prepared Queryと同時に使用できない 60

不満：重複除去(DISTINCT)が苦手既にUniqueであることを認識できない SELECT DISTINCT i FROM (SELECT DISTINCT i FROM t) t; Unique → Unique → Sort → SeqScan Uniqueの前倒し最適化ができない SELECT DISTINCT t1.i FROM t1, t2 WHERE t1.i = t2.i; Unique → Join → 2×(Sort + Scan) SELECT t1.i FROM (SELECT DISTINCT i FROM t1) t1, (SELECT DISTINCT i FROM t2) t2 WHERE t1.i = t2.i; Join → 2×(Unique + Sort + Scan) 61

不満：拡張性の不足ユーザ定義拡張に対する拡張性ユーザ定義関数選択度の指定は不可コスト (CPU, IO)の指定は不可ユーザ定義テーブル関数返す行数の指定は不可 (常に1000) 例：dblink (複数サーバへの分散問合せ) SELECT * FROM dblink(server1, ‘SELECT…') AS t1(…), dblink(server2, ‘SELECT…') AS t2(…) WHERE t1.foo = t2.foo; 1000行だと仮定して最適化 62

不満：OracleにあってPostgreSQLにない基本的な動作は同等コストベース最適化 (全探索) 統計情報 (ヒストグラムなど) Oracle限定機能ヒント機能強制的に特定のアクセスパスを使わせるパラレル化一つのクエリを複数のスレッドで並行処理アドバイザと自動化 SQLを収集し、索引の追加を提案統計情報収集用のパラメータの自動調整 63

EXPLAINコマンド EXPLAIN : 実行計画を見るためのコマンド例 EXPLAIN SELECT i FROM tbl WHERE i = 10; 出力 Index Scan using idx on tbl ① (cost=0.00..3.07 rows=5 width=4) Index Cond: (i = 10) ② ③ 解釈 ① テーブル tbl をインデックス idx を使って読み取り ② 初期コストは0.00, 総合コストは3.07 ③ 5行が出力されると推定 64

例：SQLの書き方とインデックスの使用可否 1. min, max (8.0以前) SELECT min(x) FROM …; SELECT x FROM … ORDER BY x LIMIT 1; 2. キャスト (7.4以前) WHERE int8column = 4; WHERE int8column = 4::int8; ※8.0以降も int4→OID→int8 のキャストには注意 3. 計算 WHERE lower(文字列) = ‘abc’; CREATE INDEX index ON table ( lower(文字列) ); WHERE floor(整数/10) = 16; WHERE 整数 BETWEEN 10*16 AND 10*(16+1)-1; 65

例：統計情報の精度不足サンプリング数の設定 ALTER TABLE table ALTER column SET STATISTICS 1-1000 ; EXPLAIN ANALYZE SELECT … FROM order_line, item WHERE ol_o_id = N AND ol_i_id = i_id ORDER BY ol_i_id; STATISTICS = 10 Merge Join (cost=2779.93 rows=1832) (actual time=116.244 rows=3) Merge Cond: ("outer".ol_i_id = "inner".i_id) → Sort (rows=1834) (rows=3) Sort Key: ol_i_id → Index Scan using idx_ol_o_id on order_line (rows=1834) (rows=3) Index Cond: (ol_o_id = N::numeric) → Sort (rows=10010) (rows=7924) Sort Key: i_id → Seq Scan on item i (rows=10010) (rows=10000) STATISTICS = 1000 Sort (cost=53.69 rows=16) (actual time=0.125 rows=3) Sort Key: ol_i_id → Nested Loop (rows=16) (rows=3) → Index Scan using idx_ol_o_id on order_line (rows=16) (rows=3) Index Cond: (ol_o_id = N::numeric) → Index Scan using pk_i on item (rows=1) (rows=1) Index Cond: ("outer".ol_i_id = i_id) 66

例：統計情報の精度不足 Join ol_o_id = i_id 候補の実行計画 NestLoop order_line item order_line NestLoop item ol_o_id = N 40M行 10000行 MergeJoin (or HashJoin) order_line sort MergeJoin item sort 不正確な統計情報でのコスト 1834回のIndexScan ＞ (1834+10010)件のソート正確な統計情報でのコスト 16回のIndexScan ＜ (16+10010)件のソート 67

問合せ最適化インサイド

by Takahiro Itagaki on Jul 01, 2010

Accessibility

Categories

Tags

Upload Details

Usage Rights

Statistics

問合せ最適化インサイド — Presentation Transcript