VACUUM — データベースの不要領域の回収とデータベースの解析(オプション)を行う
VACUUM [ ( { FULL | FREEZE | VERBOSE | ANALYZE } [, ...] ) ] [table_name
[ (column_name
[, ...] ) ] ] VACUUM [ FULL ] [ FREEZE ] [ VERBOSE ] [table_name
] VACUUM [ FULL ] [ FREEZE ] [ VERBOSE ] ANALYZE [table_name
[ (column_name
[, ...] ) ] ]
VACUUM
は、不要タプルが使用する領域を回収します。
PostgreSQLの通常動作では、削除されたタプルや更新によって不要となったタプルは、テーブルから物理的には削除されません。
これらのタプルはVACUUM
が完了するまで存在し続けます。
そのため、特に更新頻度が多いテーブルでは、VACUUM
を定期的に実行する必要があります。
パラメータの指定がない場合、VACUUM
は現在のユーザがバキュームできる権限を持つ、現在のデータベース内の全てのテーブルを処理します。
パラメータを指定した場合、VACUUM
は指定したテーブルのみを処理します。
VACUUM ANALYZE
は、指定したテーブルの1つひとつに対し、VACUUM
を行った後、ANALYZE
を行います。
このコマンドの組合わせは、日常的な管理スクリプトで使うと便利です。
処理の詳細に関しては、ANALYZEを参照してください。
(FULL
が指定されていない)通常のVACUUM
は、単に領域を回収し、そこを再利用可能な状態に変更します。
この形式のコマンドでは排他的ロックを取得しないため、テーブルへの通常の読み書き操作と並行して実行することができます。
しかし余った領域はオペレーティングシステムには(ほとんどの場合)返されません。
同じテーブル内で再利用できるように保持されるだけです。
VACUUM FULL
では、テーブルの内容全体を新しいディスクファイルに領域を余すことなく書き換えるため、オペレーティングシステムに未使用の領域を返すことができます。
この形式では、実行速度がかなり低速になります。また、処理中のテーブルに対する排他的ロックが必要になります。
オプションリストが括弧でくくられていた場合、オプションを任意の順序で記述することができます。 括弧がないと、オプションは上で示した通りの順番で指定しなければなりません。 括弧付きの構文はPostgreSQL 9.0で追加されました。 カッコがない構文は廃止予定です。
FULL
より多くの領域の回収することができる「完全な」バキュームを選択します。 ただし、通常よりも処理に時間がかかります。 また、テーブルに対する排他ロックが必要です。 またこの方式では、テーブルのコピーを新しく書き出し、操作が終わるまで古いコピーが解放されませんので、余分にディスク領域が必要です。 通常、大きな容量がテーブルから回収されなければならない場合にのみこれが使用されるべきです。
FREEZE
積極的なタプルの「凍結」を選択します。
FREEZE
指定は、vacuum_freeze_min_ageおよびvacuum_freeze_table_ageパラメータをゼロとしてVACUUM
を実行することと同じです。
テーブルが書き換えられる時は、必ず積極的な凍結が行われるので、FULL
が指定されているときは、このオプションは冗長です。
VERBOSE
各テーブルについてバキューム処理の詳細な報告を出力します。
ANALYZE
プランナが使用する統計情報を更新し、問い合わせを実行する最も効率的な方法を決定できるようにします。
table_name
バキューム対象のテーブル名です(スキーマ修飾名も可)。 デフォルトは現在のデータベース内の全テーブルです。
column_name
解析の対象とする列名です。デフォルトは全列です。
列リストが指定された場合はANALYZE
を暗示します。
VERBOSE
が指定された場合、VACUUM
は、現在処理中のテーブルを示す進行状況メッセージを表示します。
同様に、テーブルについての各種の統計情報も表示されます。
テーブルをバキュームするためには、通常はテーブルの所有者もしくはスーパーユーザでなければなりません。
しかしデータベースの所有者は共有カタログを除くデータベース内の全テーブルをバキュームすることができます。
(共有カタログに関する制限は、データベース全体のVACUUM
はスーパーユーザのみが実行可能であることを意味します。)
VACUUM
は、呼び出したユーザがバキュームするための権限を持たないテーブルはすべて飛ばします。
トランザクションブロック内でVACUUM
を実行することはできません。
GINインデックスを持つテーブルでは、VACUUM
(全構文)は待ち状態のインデックス挿入を主GINインデックス構造内の適切なところに移動させることにより、待ち状態のインデックス挿入をすべて完了させます。
61.4.1. GIN高速更新手法を参照してください。
不要となった行を削除するため、実運用状態のデータベースに対しては定期的に(少なくとも毎晩)VACUUM
を実行することを推奨します。
また、テーブルに対して多数の行を追加/削除した後は、そのテーブルにVACUUM ANALYZE
を発行することを推奨します。
これによりシステムカタログに最近なされた全ての変更が反映されることになり、PostgreSQLの問い合わせプランナが、問い合わせ計画の作成時により良い選択をできるようになります。
FULL
オプションを日常的に使用することは推奨しませんが、特殊なケースでは有用となる場合もあります。
例えば、テーブル内のほとんど全ての行を削除または更新し、そのテーブルによるディスクの使用量を物理的に縮小させて高速なテーブルスキャンを行いたい場合です。
VACUUM FULL
はたいていの場合、通常のVACUUM
よりもテーブルを縮小します。
VACUUM
によりI/Oトラフィックがかなり増大しますので、実行中の他のセッションの性能が悪化する可能性があります。
このため、コストベースのバキューム遅延機能の使用が推奨される場合があります。
詳細は18.4.4. コストに基づくVacuum遅延を参照してください。
PostgreSQLには、バキューム保守作業を自動化する「autovacuum」機能があります。 自動バキューム処理および手作業によるバキューム処理に関する詳細については、23.1. 定常的なバキューム作業を参照してください。
下記の例は、regressionデータベース内のテーブルにVACUUM
を実行したものです。
regression=# VACUUM (VERBOSE, ANALYZE) onek; INFO: vacuuming "public.onek" INFO: index "onek_unique1" now contains 1000 tuples in 14 pages DETAIL: 3000 index tuples were removed. 0 index pages have been deleted, 0 are currently reusable. CPU 0.01s/0.08u sec elapsed 0.18 sec. INFO: index "onek_unique2" now contains 1000 tuples in 16 pages DETAIL: 3000 index tuples were removed. 0 index pages have been deleted, 0 are currently reusable. CPU 0.00s/0.07u sec elapsed 0.23 sec. INFO: index "onek_hundred" now contains 1000 tuples in 13 pages DETAIL: 3000 index tuples were removed. 0 index pages have been deleted, 0 are currently reusable. CPU 0.01s/0.08u sec elapsed 0.17 sec. INFO: index "onek_stringu1" now contains 1000 tuples in 48 pages DETAIL: 3000 index tuples were removed. 0 index pages have been deleted, 0 are currently reusable. CPU 0.01s/0.09u sec elapsed 0.59 sec. INFO: "onek": removed 3000 tuples in 108 pages DETAIL: CPU 0.01s/0.06u sec elapsed 0.07 sec. INFO: "onek": found 3000 removable, 1000 nonremovable tuples in 143 pages DETAIL: 0 dead tuples cannot be removed yet. There were 0 unused item pointers. Skipped 0 pages due to buffer pins. 0 pages are entirely empty. CPU 0.07s/0.39u sec elapsed 1.56 sec. INFO: analyzing "public.onek" INFO: "onek": 36 pages, 1000 rows sampled, 1000 estimated total rows VACUUM
標準SQLにはVACUUM
文はありません。