さまざまな視覚化オプション がこれに役立ちます：
縮小されたテキストビュー
かなり単純な計画の元のテキストは、分析時にすでに問題を引き起こします。
したがって、各ノードの実行時間と使用済みバッファーに関する重要な情報が左右に表示され、最大値に非常に簡単に気付く場合は、省略形をお勧めします。
円グラフ
しかし、「最も痛いところ」を理解するだけでも簡単ではない場合があります。特に、ノードが数十個含まれていて、計画の短縮形でさえ2〜3画面かかる場合はなおさらです。
この場合、通常の円グラフが
役に立ちます。すぐに、各ノードによるリソース消費のおおよそのシェアを確認できます。その上にカーソルを合わせると、テキストビューの左側に、選択したノードのアイコンが表示されます。
タイル
残念ながら、piechartは、異なるノードと「最もホットな」ポイントとの関係を示していません。このためには、「タイル」オプションの方がはるかに適しています。
実行図
ただし、これらのオプションはどちらも、サービスノードのアタッチメントの完全なチェーンを示していません。
CTE/InitPlain/SubPlan実際の実行図でのみ確認できます。
より多くのメトリックが必要です！
クエリの実際の実行の計画をとして撮影すると、そこには経過時間のみ
EXPLAIN (ANALYZE)が表示されます。しかし、多くの場合、これでは正しい結論を出すには不十分です。
たとえば、「コールド」キャッシュでクエリを実行すると、メディアからデータを受信した時刻が表示されます（ただし、表示されません）。クエリ自体の操作はまったく表示されません。
したがって、いくつかの推奨事項：
- 差し引かれるデータページの量を確認するために使用します。この値は、実際にはサーバー自体の負荷による変動の影響を受けず、最適化のメトリックとして使用できます。
EXPLAIN (ANALYZE, BUFFERS) - キャリアでの作業
track_io_timingにかかった時間を正確に理解するために使用します。
あなたの計画が含まれている場合といないだけの時間をも、
buffersあるいはi/o timings、その後、図のオプションのそれぞれに、あなたは、これらのメトリックの分析モードに切り替えることができます。たとえば、すべての読み取り値の半分以上が単一の問題ノードに分類されていることがすぐにわかる場合があります。
このトピックに関する以前の記事：
- PostgreSQLクエリプランをさらに便利に理解する
- 病んでいるSQLクエリのレシピ
- EXPLAINが沈黙していること、そして彼に話をさせる方法