概要
EXPLAIN [ ( option [, ...] ) ] 文
EXPLAIN [ ANALYZE ] [ VERBOSE] ステートメント
ここで、オプションは次のいずれかになります。
ANALYZE [ブール値]
VERBOSE [ブール値]
コスト [ブール値]
SETTINGS [ブール]
GENERIC_PLAN [ブール値]
BUFFERS [ブール]
WAL [ブール]
TIMING [ブール値]
概要 [ブール値]
FORMAT {テキスト | XML | JSON | YAML } 説明
このコマンドは、指定されたステートメントに対してPostgreSQLplannerが生成する実行プランを表示します。 実行計画は、ステートメントによって参照されるテーブルがどのようにスキャンされるかを示します-単純なシーケンシャルスキャン、インデックススキャンなどによって。-複数のテーブルが参照されている場合、各入力テーブルから必要な行をまとめるためにどの結合アルゴリズムが使用されます。
表示の最も重要な部分は、推定されたステートメント実行コストであり、これは、ステートメントを実行するのにかかる時間をプランナが推測するものである (任意のコスト単位で測定されるが、従来はディスクページのフェッチを意味する) 。 実際には、最初の行を返す前の起動コストと、すべての行を返すための合計コストの2つの数値が表示されます。 ほとんどのクエリでは総コストが重要ですが、EXISTSのサブクエリなどのコンテキストでは、プランナーは最小の総コストではなく最小の起動コストを選択します (とにかく、エグゼキュータは1行を取得した後に停止するため) 。 また、limit句で返される行数を制限すると、プランナーはエンドポイントコスト間で適切な補間を行い、実際に最も安いプランを見積もります。
ANALYZEオプションを使用すると、ステートメントが実際に実行されます。 次に、各プランノード内で費やされた合計経過時間 (ミリ秒単位) と実際に返された行の総数を含む、実際の実行時間統計がディスプレイに追加されます。 これは、プランナーの見積もりが現実に近いかどうかを確認するのに役立ちます。
ANALYZEオプションを使用すると、ステートメントが実際に実行されることに注意してください。 EXPLAINはSELECTが返すすべての出力を破棄しますが、ステートメントのその他の副作用は通常どおり発生します。 コマンドをデータに影響させずに、INSERT、UPDATE、DELETE、MERGE、CREATE TABLE AS、またはEXECUTEステートメントでEXPLAIN ANALYZEを使用する場合は、次の方法を使用します。
BEGIN;
分析の説明...;
ロールバック; ANALYZEオプションとVERBOSEオプションのみを指定でき、オプションリストを括弧で囲んでいません。
パラメーター
分析: コマンドを実行し、実際の実行時間とその他の統計を表示します。 このパラメーターのデフォルトはFALSEです。VERBOSE: プランに関する追加情報を表示します。 具体的には、プランツリーの各ノードの出力列リスト、スキーマ修飾テーブルおよび関数名を含め、常に範囲テーブルのエイリアスを使用して式の変数にラベルを付け、統計が表示される各トリガーの名前を常に出力します。 クエリ識別子が計算された場合、クエリ識別子も表示されます。 このパラメーターのデフォルトはFALSEです。コスト: 各プランノードの推定起動コストと総コスト、および推定行数と推定各行幅に関する情報を含めます。 このパラメーターのデフォルトはTRUEです。SETTINGS: 設定パラメーターに関する情報を含めます。 具体的には、組み込みのデフォルト値とは異なる値でクエリ計画に影響を与えるオプションを含めます。 このパラメーターのデフォルトはFALSEです。バッファ: バッファの使用状況に関する情報を含めます。 具体的には、track_io_timingが有効化されている場合、共有ブロックのヒット、読み取り、ダーティ、および書き込み数、ローカルブロックのヒット、読み取り、ダーティ、および書き込み数、一時ブロックの読み取りおよび書き込みに費やされる時間、データファイルブロックおよび一時ファイルブロックの読み取りおよび書き込みに費やされる時間 (ミリ秒) を含みます。 ヒットは、必要なときにブロックがすでにキャッシュ内に見つかったため、読み取りが回避されたことを意味します。 共有ブロックには通常のテーブルとインデックスからのデータが含まれ、ローカルブロックには一時的なテーブルとインデックスからのデータが含まれます。 dirtiedブロックの数は、このクエリによって変更された以前に変更されていないブロックの数を示し、書き込まれたブロックの数は、クエリ処理中にこのバックエンドによってキャッシュから追い出された以前にdirtiedされたブロックの数を示す。 上位ノードについて示されるブロックの数は、そのすべての子ノードによって使用されるものを含む。 テキストフォーマットでは、非ゼロ値のみが印刷される。 このパラメーターのデフォルトはFALSEです。WAL: WALレコードの生成に関する情報を含めます。 具体的には、レコードの数、フルページイメージの数 (fpi) 、および生成されたWALの量をバイト単位で含む。 テキストフォーマットでは、非ゼロ値のみが印刷される。 このパラメーターは、ANALYZEも有効な場合にのみ使用できます。 デフォルトはFALSEです。TIMING: 実際の起動時間と各ノードで費やされた時間を出力に含めます。 システムクロックを繰り返し読み取るオーバーヘッドは、一部のシステムではクエリの速度を大幅に低下させる可能性があるため、正確な時間ではなく実際の行カウントのみが必要な場合にこのパラメータをFALSEに設定すると便利です。 このオプションでノードレベルのタイミングがオフになっている場合でも、ステートメント全体の実行時間は常に測定されます。 このパラメーターは、ANALYZEも有効な場合にのみ使用できます。 デフォルトはTRUEです。要約: クエリプランの後に要約情報 (例えば、合計されたタイミング情報) を含める。 サマリー情報は、ANALYZEを使用する場合はデフォルトで含まれますが、それ以外の場合はデフォルトで含まれませんが、このオプションを使用して有効にできます。EXPLAIN EXECUTEの計画時間には、キャッシュから計画をフェッチするのに必要な時間と、必要に応じて再計画に必要な時間が含まれます。FORMAT: 出力形式を指定します。TEXT、XML、JSON、またはYAMLです。 非テキスト出力には、テキスト出力形式と同じ情報が含まれていますが、プログラムでは簡単に解析できます。 このパラメーターのデフォルトはTEXTです。boolean: 選択したオプションをオンにするかオフにするかを指定します。 オプションを有効にするにはTRUE、ON、または1と記述し、オプションを無効にするにはFALSE、OFF、または0と記述します。ブール値は省略することもでき、その場合はTRUEと仮定される。ステートメント:SELECT、INSERT、UPDATE、DELETE、MERGE、VALUES、EXECUTE、DECLARE、CREATE TABLE AS、またはCREATE MATERIALIZVIEW ASステートメント。
出力
コマンドの結果は、ステートメントのために選択されたプランのテキスト記述であり、オプションで実行統計で注釈が付けられます。
注
PolarDB PostgreSQLクエリプランナーがクエリを最適化するときに合理的な情報に基づいた決定を行えるようにするには、クエリで使用されるすべてのテーブルでデータ pg_統計を最新のものにする必要があります。 通常、自動真空デーモンはそれを自動的に処理します。 ただし、最近テーブルの内容が大幅に変更された場合は、自動真空が変更に追いつくのを待つのではなく、手動で分析を行う必要があります。
実行計画の各ノードの実行時コストを測定するために、現在のEXPLAIN ANALYZEの実装では、クエリの実行にプロファイリングのオーバーヘッドが追加されます。 その結果、クエリでEXPLAIN ANALYZEを実行すると、クエリを通常実行するよりもかなり時間がかかることがあります。 オーバーヘッドの量は、クエリの性質、および使用されているプラットフォームに依存します。 最悪のケースは、実行ごとに非常に短い時間しか必要としないプランノード、および時刻を取得するためのオペレーティングシステムコールが比較的遅いマシンで発生します。
例
単一の整数列と10000行を持つテーブルに対する単純なクエリの計画を表示するには:
EXPLAIN SELECT * FROM foo;
クエリプラン
---------------------------------------------------------
Seqスキャンon foo (コスト=0.00 .. 155.00行=10000幅=4)
(1行) JSON出力フォーマットを使用した同じクエリを次に示します。
EXPLAIN (フォーマットJSON) SELECT * FROM foo;
クエリプラン
--------------------------------
[ +
{ +
"プラン": { +
「ノードタイプ」: 「Seqスキャン」、+
"Relation Name": "foo", +
"エイリアス": "foo", +
「スタートアップコスト」: 0.00、+
「総コスト」: 155.00、+
「プラン行」: 10000、+
「プラン幅」: 4 +
} +
} +
]
(1行) インデックスがあり、インデックス可能なWHERE条件を持つクエリを使用する場合、EXPLAINは別のプランを示す可能性があります。
EXPLAIN SELECT * FROM foo WHERE i = 4;
クエリプラン
--------------------------------------------------------------
fooでfiを使用したインデックススキャン (コスト=0.00 .. 5.98行=1幅=4)
Index Cond :( i = 4)
(2行) これは同じクエリですが、YAML形式です。
EXPLAIN (フォーマットYAML) SELECT * FROM foo WHERE i='4';
クエリプラン
-------------------------------
-プラン: +
ノードタイプ: "Index Scan" +
スキャン方向: 「前方」 +
インデックス名: "fi" +
関係名: "foo" +
エイリアス: "foo" +
スタートアップコスト: 0.00 +
総コスト: 5.98 +
プラン行: 1 +
プラン幅: 4 +
Index Cond: "(i = 4)"
(1行) コスト見積もりが抑制された同じ計画は次のとおりです。
EXPLAIN (COSTS FALSE) SELECT * からfoo WHERE i = 4;
クエリプラン
----------------------------
fooでfiを使用したインデックススキャン
Index Cond :( i = 4)
(2行) 集計関数を使用したクエリのクエリプランの例を次に示します。
EXPLAIN SELECT sum(i) foo WHERE i < 10;
クエリプラン
---------------------------------------------------------------------
集計 (コスト=23.93 .. 23.93行=1幅=4)
-> fooでfiを使用したインデックススキャン (コスト=0.00 .. 23.92行=6幅=4)
Index Cond :( i < 10)
(3行) EXPLAIN EXECUTEを使用して、準備されたクエリの実行計画を表示する例を次に示します。
PREPAREクエリ (int、int) AS SELECT sum(bar) FROM test
WHERE id > $1 AND id < $2
fooによるグループ;
EXPLAIN ANALYZE EXECUTEクエリ (100、200);
クエリプラン
------------------------------------------------------------------------------------------------------------------------
HashAggregate (コスト=9.54 .. 9.54行=1幅=8) (実際の時間=0.156 .. 0.161行=11ループ=1)
グループキー: foo
-> テスト時にtest_pkeyを使用したインデックススキャン (コスト=0.29 .. 9.29行=50幅=8) (実際の時間=0.039 .. 0.091行=99ループ=1)
Index Cond :( (id > $1) AND (id < $2))
計画時間: 0.197 ms
実行時間: 0.225 ms
(6行) もちろん、ここに示される特定の数は、関係するテーブルの実際の内容に依存する。 また、プランナーの改善により、数値、さらには選択したクエリ戦略でさえ、PostgreSQLreleases間で異なる場合があります。 さらに、ANALYZEコマンドはランダムサンプリングを使用してデータ統計を推定します。したがって、テーブル内のデータの実際の分布が変更されていない場合でも、ANALYZEの新しい実行後にコスト推定値が変更される可能性があります。