PostgreSQLは、何らかのコマンドの実行中に進捗状況をレポートする能力があります。
現在、進捗状況のレポートをサポートしているのは、CREATE INDEX、VACUUM、および、CLUSTERのみです。
将来的にサポートされるコマンドが拡大される可能性があります。
CREATE INDEXやREINDEXが実行中であるときにはいつでも、pg_stat_progress_create_indexビューには現在インデックスを作成している各バックエンドごとの行が含まれます。
表27.22 pg_stat_progress_create_indexビュー
| 列 | 型 | 説明 |
|---|---|---|
pid | integer | バックエンドのプロセスID。 |
datid | oid | このバックエンドが接続されているデータベースのOID。 |
datname | name | このバックエンドが接続されているデータベース名。 |
relid | oid | インデックスが作られているテーブルのOID。 |
index_relid | oid |
作成または再作成されているインデックスのOID。
同時作成ではないCREATE INDEXのときは、これは0です。
|
command | text |
実行しているコマンドで、
CREATE INDEX、
CREATE INDEX CONCURRENTLY、
REINDEXまたはREINDEX CONCURRENTLYです。
|
phase | text | 現在処理中のインデックス作成のフェーズです。 表 27.23を参照してください。 |
lockers_total | bigint | 該当するときに、待機するロック取得者の総数。 |
lockers_done | bigint | 既に待機したロック取得者の数。 |
current_locker_pid | bigint | 現在待機しているロック取得者のプロセスID。 |
blocks_total | bigint | 現在のフェーズで処理されることになっているブロックの総数。 |
blocks_done | bigint | 現在のフェーズで既に処理されたブロック数。 |
tuples_total | bigint | 現在のフェーズで処理されることになっているタプルの総数。 |
tuples_done | bigint | 現在のフェーズで既に処理されたタプル数。 |
partitions_total | bigint | パーティションテーブル上のインデックスを作成するとき、この列にはインデックスが作られることになっているパーティションの総数が設定されます。 |
partitions_done | bigint | パーティションテーブル上のインデックスを作成するとき、この列にはインデックス作成が既に完了しているパーティションの数が設定されます。 |
表27.23 CREATE INDEX Phases
| フェーズ | 説明 |
|---|---|
initializing |
CREATE INDEXやREINDEXはインデックスを作る準備をしています。
このフェーズはごく短時間になると予想されます。
|
waiting for writers before build |
CREATE INDEX CONCURRENTLYやREINDEX CONCURRENTLYは、潜在的にテーブルを参照するかもしれない書き込みロックを伴うトランザクションが終了するのを待機しています。
本フェーズは同時モードでないときには省かれます。
列lockers_total、lockers_done、および、current_locker_pidには本フェーズの進行情報が入ります。
|
building index |
インデックスがアクセスメソッド固有のコードにより作成されています。
本フェーズでは、進捗レポートをサポートするアクセスメソッドが自身の進捗データを記入し、また、サブフェーズはこの列で示されます。
典型的には、blocks_totalとblocks_doneが、さらにあるいはtuples_totalとtuples_doneも、進捗データを含みます。
|
waiting for writers before validation |
CREATE INDEX CONCURRENTLYやREINDEX CONCURRENTLYは、潜在的にテーブルに書き込みするかもしれない書き込みロックを伴うトランザクションが終了するのを待機しています。
本フェーズは同時モードでないときには省かれます。
列lockers_total、lockers_done、および、current_locker_pidには本フェーズの進行情報が入ります。
|
index validation: scanning index |
CREATE INDEX CONCURRENTLYは確認が必要なタプルに対するインデックス検索をスキャンしています。
本フェーズは同時モードでないときには省かれます。
列blocks_total（インデックスの総サイズが設定される）とblocks_doneに本フェーズの進行情報が入ります。
|
index validation: sorting tuples |
CREATE INDEX CONCURRENTLYはインデックスをスキャンするフェーズ(scanning index)の出力をソートしています。
|
index validation: scanning table |
CREATE INDEX CONCURRENTLYは、前の2フェーズで収集されたインデックスのタプルを確認するためテーブルをスキャンしています。
本フェーズは同時モードでないときには省かれます。
列blocks_total（テーブルの総サイズが設定される）とblocks_doneに本フェーズの進行情報が入ります。
|
waiting for old snapshots |
CREATE INDEX CONCURRENTLYやREINDEX CONCURRENTLYは、潜在的にテーブルを参照するかもしれないトランザクションがそれらのスナップショットを解放するのを待機しています。
本フェーズは同時モードでないときには省かれます。
列lockers_total、lockers_done、および、current_locker_pidには本フェーズの進行情報が入ります。
|
waiting for readers before marking dead |
REINDEX CONCURRENTLYは、古いインデックスに無効と印付けする前に、テーブルへの読み取りロックを伴うトランザクションが終了するのを待機しています。
本フェーズは同時モードでないときには省かれます。
列lockers_total、lockers_done、および、current_locker_pidには本フェーズの進行情報が入ります。
|
waiting for readers before dropping |
REINDEX CONCURRENTLYは、古いインデックスを削除する前に、テーブルへの読み取りロックを伴うトランザクションが終了するのを待機しています。
本フェーズは同時モードでないときには省かれます。
列lockers_total、lockers_done、および、current_locker_pidには本フェーズの進行情報が入ります。
|
VACUUMを実行するときはいつでも、pg_stat_progress_vacuumビューは、現在バキューム処理している（自動バキュームワーカプロセスを含む）それぞれのバックエンドごとに１行を格納します。
その情報を説明している以下のテーブルにおいて、何がレポートされ、どのように解釈するかについての情報を提供します。
VACUUM FULLコマンドの進捗はpg_stat_progress_clusterでレポートされます。これは、通常のVACUUMはテーブル内を書き換えするのみである一方、VACUUM FULLとCLUSTERはいずれもテーブルを再作成するためです。
27.4.3を参照してください。
表27.24 pg_stat_progress_vacuumビュー
| 列 | 型 | 説明 |
|---|---|---|
pid | integer | バックエンドのプロセスID。 |
datid | oid | このバックエンドが接続されたデータベースのOID。 |
datname | name | このバックエンドが接続されたデータベース名。 |
relid | oid | バキューム処理が行われているテーブルのOID。 |
phase | text | 現在のバキュームの処理フェーズ。表 27.25を参照してください。 |
heap_blks_total | bigint |
テーブルのヒープブロックの総数。
この数字は、スキャンの開始を基点としてレポートされます。
後に追加されるブロックは、このVACUUMによって処理されません（必要もありません）。
|
heap_blks_scanned | bigint |
スキャンされたヒープブロックの数。
可視性マップがスキャンを最適化するために使用されるため、いくつかのブロックが検査されずに読み飛ばされます。
読み飛ばされたブロックはこの総数に含まれ、そのためこの数字はバキューム処理が完了した時に、最終的にheap_blks_totalと同じになります。
このカウンタは、フェーズがscanning heapの時にのみ増加します。
|
heap_blks_vacuumed | bigint |
バキューム処理されたヒープブロックの数。
テーブルにインデックスが１つでも存在するなら、このカウンタはフェーズがvacuuming heapの時にのみ増加します。
無効なタプルが含まれていないブロックは読み飛ばされ、それゆえカウンタは時々大きな増加量で早送りされます。
|
index_vacuum_count | bigint | 完了したインデックスバキュームサイクルの数。 |
max_dead_tuples | bigint | インデックスバキュームサイクルの実行に必要となる前に格納することが出来る、maintenance_work_memに基づいた、無効なタプルの数。 |
num_dead_tuples | bigint | 最後のインデックスバキュームサイクルから収集された無効タプルの数。 |
表27.25 VACUUMのフェーズ
| フェーズ | 説明 |
|---|---|
initializing |
VACUUMは、ヒープをスキャンし始める準備をしています。
このフェーズは、非常に短時間であると予想されます。
|
scanning heap |
VACUUMは、現在ヒープをスキャン中です。
必要であればそれぞれのページを切り取り、デフラグし、場合によってはフリーズ活動を実行します。
スキャンの進捗状況の監視にheap_blks_scanned列が使用できます。
|
vacuuming indexes |
VACUUMは、現在インデックスをバキューム処理中です。
テーブルにインデックスが存在する場合、ヒープが完全にスキャンされた後に、バキューム実行ごとに少なくとも１回発生します。
maintenance_work_memが、発見された無効タプルの数量を格納するのに不十分な場合は、バキューム実行ごとに複数回発生する可能性があります。
|
vacuuming heap |
VACUUMは、現在ヒープをバキューム処理中です。
ヒープのバキュームは、ヒープのスキャンと異なり、インデックスをバキューム処理するそれぞれのインスタンスの後に発生します。
heap_blks_scannedがheap_blks_totalより少ない場合、システムはこのフェーズの完了後にヒープのスキャン処理に戻ります。
さもなければ、このフェーズの完了後にインデックスの整理を始めます。
|
cleaning up indexes |
VACUUMは、現在インデックスの整理処理中です。
これは、ヒープが完全にスキャンされ、インデックスとヒープが完全にすべてバキューム処理された後に発生します。
|
truncating heap |
VACUUMは、現在リレーションの終点の空のページをオペレーティングシステムに戻すためにヒープを削除しています。
これは、インデックスの整理処理後に発生します。
|
performing final cleanup |
VACUUMは、最終クリーンアップ処理をしています。
このフェーズの間、VACUUM空き領域マップをバキュームし、pg_classの統計情報を更新し、統計情報コレクタに統計情報を報告します。
このフェーズが完了した時、VACUUMは終了します。
|
CLUSTERやVACUUM FULLが実行されているときにはいつでも、pg_stat_progress_clusterビューには現在いずれかのコマンドを実行している各バックエンドごとの行が含まれます。
以下の表は、報告される情報を説明し、どのように解釈するかの情報を提供します。
表27.26 pg_stat_progress_clusterビュー
| 列 | 型 | 説明 |
|---|---|---|
pid | integer | バックエンドのプロセスID。 |
datid | oid | バックエンドが接続されているデータベースのOID。 |
datname | name | バックエンドが接続されているデータベース名。 |
relid | oid | クラスタ化されているテーブルのOID。 |
command | text |
実行しているコマンド。
CLUSTERかVACUUM FULLのいずれかです。
|
phase | text | 現在処理中のフェーズ。 表 27.27を参照してください。 |
cluster_index_relid | oid | テーブルがインデックスを使ってスキャンされているのであれば、これは使われているインデックスのOIDで、さもなくばゼロです。 |
heap_tuples_scanned | bigint |
スキャンされたヒープタプルの数。
このカウンタは、フェーズがseq scanning heap、index scanning heap、または、writing new heapであるときのみ前進します。
|
heap_tuples_written | bigint |
書かれたヒープタプルの数。
このカウンタは、フェーズがseq scanning heap、index scanning heap、または、writing new heapであるときのみ前進します。
|
heap_blks_total | bigint |
テーブル内のヒープブロックの総数。
この数にはseq scanning heapの開始時の値が報告されます。
|
heap_blks_scanned | bigint |
スキャンされたヒープブロックの数。
このカウンタは、フェーズがseq scanning heapであるときのみ前進します。
|
index_rebuild_count | bigint |
インデックス再作成の数。
このカウンタはフェーズがrebuilding indexであるときのみ前進します。
|
表27.27 CLUSTERとVACUUM FULLのフェーズ
| フェーズ | 説明 |
|---|---|
initializing | コマンドはヒープのスキャンを開始する準備をしています。 本フェーズはごく短時間になると予想されます。 |
seq scanning heap | コマンドは現在、テーブルをシーケンシャルスキャンを使ってスキャンしています。 |
index scanning heap |
CLUSTERは現在、インデックススキャンを使ってテーブルをスキャンしています。
|
sorting tuples |
CLUSTERは現在、タプルをソートしています。
|
writing new heap |
CLUSTERが新しいヒープに書き込んでいます。
|
swapping relation files | コマンドは現在、新たに構築したファイルを置き換えて設置しています。 |
rebuilding index | コマンドは現在、インデックスを再構築しています。 |
performing final cleanup |
コマンドは現在、最終クリーンアップを実行中です。
このフェーズが完了すると、CLUSTERやVACUUM FULLは終了します。
|