半年前 - 公共 PostgreSQLに。
過去数か月間、私たちは彼についていろいろなことをしてきました 、まとめを用意しました 提供される推奨事項に基づいています...しかし最も重要なのは、私たちが皆さんからのフィードバックを収集し、実際の使用例を検討したことです。
使用できる新機能についてお知らせする準備が整いました。
さまざまなプラン形式のサポート
リクエストに合わせてログから計画
コンソールから直接、次の行から始まるブロック全体を選択します。 クエリテキスト、先頭にすべてスペースを入れます。
Query Text: INSERT INTO dicquery_20200604 VALUES ($1.*) ON CONFLICT (query)
DO NOTHING;
Insert on dicquery_20200604 (cost=0.00..0.05 rows=1 width=52) (actual time=40.376..40.376 rows=0 loops=1)
Conflict Resolution: NOTHING
Conflict Arbiter Indexes: dicquery_20200604_pkey
Tuples Inserted: 1
Conflicting Tuples: 0
Buffers: shared hit=9 read=1 dirtied=1
-> Result (cost=0.00..0.05 rows=1 width=52) (actual time=0.001..0.001 rows=1 loops=1)
...コピーしたものを何も分割せずに、プランのフィールドに直接スローします。
出力時には、分解された計画へのボーナスも得られます コンテキストタブここでは、私たちのリクエストがその栄光の中で表現されています。
JSON と YAML
EXPLAIN (ANALYZE, BUFFERS, FORMAT JSON)
SELECT * FROM pg_class;"[
{
"Plan": {
"Node Type": "Seq Scan",
"Parallel Aware": false,
"Relation Name": "pg_class",
"Alias": "pg_class",
"Startup Cost": 0.00,
"Total Cost": 1336.20,
"Plan Rows": 13804,
"Plan Width": 539,
"Actual Startup Time": 0.006,
"Actual Total Time": 1.838,
"Actual Rows": 10266,
"Actual Loops": 1,
"Shared Hit Blocks": 646,
"Shared Read Blocks": 0,
"Shared Dirtied Blocks": 0,
"Shared Written Blocks": 0,
"Local Hit Blocks": 0,
"Local Read Blocks": 0,
"Local Dirtied Blocks": 0,
"Local Written Blocks": 0,
"Temp Read Blocks": 0,
"Temp Written Blocks": 0
},
"Planning Time": 5.135,
"Triggers": [
],
"Execution Time": 2.389
}
]"pgAdmin のコピーとして外部引用符を使用しても、そうでなくても、同じフィールドにスローすると、出力は美しくなります。
高度な視覚化
計画時間 / 実行時間
これで、クエリの実行時に余分な時間がどこに費やされたのかをよりよく確認できるようになりました。
I/Oタイミング
場合によっては、リソースの観点からはそれほど多くの読み書きが行われていないように見えるのに、何らかの理由で実行時間が理解できないほど長くなるような状況に対処しなければならないことがあります。
ここで次のように言わなければなりません。ああ、その瞬間、サーバー上のディスクがおそらくビジー状態だったので、読み取りに非常に時間がかかりました。「しかし、どういうわけかそれはあまり正確ではありません...
しかし、それは絶対に確実に決定することができます。 実際、PG サーバーの構成オプションには次のようなものがあります。 :
時間指定された I/O 操作を有効にします。 この設定は、オペレーティング システムが現在時刻を常にクエリする必要があるため、デフォルトでは無効になっており、一部のプラットフォームでは動作が大幅に遅くなる可能性があります。 pg_test_timing ユーティリティを使用して、プラットフォーム上のタイミングのオーバーヘッドを推定できます。 I/O 統計は、pg_stat_database ビューを通じて取得できます。 EXPLAIN 出力内 (BUFFERS パラメーターが使用されている場合) pg_stat_statements ビューを通じて。
このオプションはローカル セッション内でも有効にすることができます。
SET track_io_timing = TRUE;さて、ここで最も重要なのは、実行ツリーのすべての変換を考慮して、このデータを理解して表示する方法を学習したことです。
ここでは、合計実行時間 0.790 ミリ秒のうち、0.718 ページのデータの読み取りに 0.044 ミリ秒、書き込みに 0.028 ミリ秒かかっており、他のすべての有用なアクティビティに費やされたのはわずか XNUMX ミリ秒であることがわかります。
PostgreSQL 13 の将来
新機能の完全な概要については、次を参照してください。 、特に計画の変更について話しています。
計画バッファー
スケジューラに割り当てられたリソースの考慮は、pg_stat_statements に関連しない別のパッチに反映されます。 BUFFERS オプションを指定した EXPLAIN は、計画段階で使用されたバッファーの数を報告します。
Seq Scan on pg_class (actual rows=386 loops=1) Buffers: shared hit=9 read=4 Planning Time: 0.782 ms Buffers: shared hit=103 read=11 Execution Time: 0.219 ms
インクリメンタルソート
多くのキー (k1、k2、k3…) による並べ替えが必要な場合、プランナーは、データが最初のキー (k1 と k2 など) のいくつかによってすでに並べ替えられているという情報を利用できるようになりました。 この場合、すべてのデータを新たに再ソートすることはできませんが、k1 と k2 の値が同じ連続するグループに分割し、キー k3 で「再ソート」します。
したがって、ソート全体は、より小さなサイズの複数の連続したソートに分割されます。 これにより、必要なメモリ量が削減され、すべての並べ替えが完了する前に最初のデータを返すことができます。
Incremental Sort (actual rows=2949857 loops=1) Sort Key: ticket_no, passenger_id Presorted Key: ticket_no Full-sort Groups: 92184 Sort Method: quicksort Memory: avg=31kB peak=31kB -> Index Scan using tickets_pkey on tickets (actual rows=2949857 loops=1) Planning Time: 2.137 ms Execution Time: 2230.019 ms
UI/UXの改善
スクリーンショットがあちこちにあります！
各タブに、すぐに実行できる機会があります。 タブのスクリーンショットをクリップボードに保存します タブの幅と奥行き全体 - 「視界」右上:
実際、この出版物のほとんどの写真はこの方法で入手されました。
ノードの推奨事項
もっとたくさんあるだけでなく、それぞれについてできること リンクに従ってください:
アーカイブから削除する
以下の能力を求めている人もいます。 「絶対に」を削除する アーカイブに公開されていない計画でも、対応するアイコンをクリックしてください。
さて、私たちが持っていることを忘れないでください コメントや提案を書き込める場所。
出所： habr.com