他のバージョンの文書10 | 9.6 | 9.5 | 9.4 | 9.3 | 9.2 | 9.1 | 9.0 | 8.4 | 8.3 | 8.2 | 8.1 | 8.0 | 7.4 | 7.3 | 7.2

VACUUM

名前

VACUUM -- データベースの不要領域の回収とデータベースの解析(オプション)を行う

概要

VACUUM [ FULL | FREEZE ] [ VERBOSE ] [ table ]
VACUUM [ FULL | FREEZE ] [ VERBOSE ] ANALYZE [ table [ (column [, ...] ) ] ]

説明

VACUUM は、削除済みのタプルが使用する領域を回収します。 PostgreSQLの通常動作では、削除されたタプルや更新によって不要となったタプルは、テーブルから物理的には削除されません。 これらのタプルはVACUUMが完了するまで存在し続けます。 そのため、特に更新頻度が多いテーブルでは、VACUUMを定期的に実行する必要があります。

パラメータの指定がない場合、VACUUMは現在のデータベース内の全てのテーブルを処理します。 パラメータを指定した場合、VACUUMは指定したテーブルのみを処理します。

VACUUM ANALYZEは、指定したテーブルの1つひとつに対し、VACUUMを行った後、ANALYZEを行います。 このコマンドの組合わせは、日常的な管理スクリプトで使うと便利です。 処理の詳細に関しては、ANALYZEを参照してください。

FULLが指定されていない)通常のVACUUMは、単に領域を回収し、そこを再利用可能な状態に変更します。 この形式のコマンドでは排他的ロックが取得されていないため、テーブルへの通常の読み書き操作と並行して実行することができます。 VACUUM FULLは、ブロック間でタプルを移動してディスクブロック数を最小にするなど、テーブルを縮小するためにより高度な処理を行います。 この形式では、実行速度がかなり低速になります。また、処理中のテーブルに対する排他的ロックが必要になります。

FREEZEは、タプルが完全に古くなるまで待つのではなく、できる限り"凍結"状態として印付けるという特殊な目的のためのオプションです。 同一データベースに対して他のトランザクションが開いていない状態でこのコマンドが実行された場合、データベース内の全タプルが"凍結"状態となることが保証されます。 この場合、どんなに長時間データベースに対するバキュームが行われていなくても、トランザクションIDの番号の回り込み問題を回避することができます。 ただし、FREEZEを日常的に使用することは推奨しません。 ユーザ定義によるtemplateデータベースや、完全に読み取り専用で、日常的なVACUUM操作を受けることがないデータベースを用意する場合のみの使用を想定しています。 詳細は第22章を参照してください。

パラメータ

FULL

領域の回収だけでなく、"完全な"バキュームを選択します。ただし、通常よりも処理に時間がかかります。また、テーブルに対する排他ロックが必要です。

FREEZE

積極的にタプルの"凍結"を選択します。

VERBOSE

各テーブルについてバキューム処理の詳細な報告を出力します。

ANALYZE

プランナが使用する統計情報を更新し、問い合わせを実行する最も効率的な方法を決定できるようにします。

table

バキューム対象のテーブル名です(スキーマ修飾名も可)。 デフォルトは現在のデータベース内の全テーブルです。

column

解析の対象とする列名です。デフォルトは全列です。

出力

VERBOSEが指定された場合、VACUUMは、現在処理中のテーブルを示す進行状況メッセージを表示します。 同様に、テーブルについての各種の統計情報も表示されます。

注釈

不要となった行を削除するため、実運用状態のデータベースに対しては(少なくとも毎晩)定期的にVACUUMを実行することを推奨します。 また、テーブルに対して多数の行を追加/削除した後は、そのテーブルにVACUUM ANALYZEを発行することを推奨します。 これによりシステムカタログに最近なされた全ての変更が反映されることになり、PostgreSQLの問い合わせプランナが、問い合わせ計画の作成時により良い選択をできるようになります。

FULLオプションを日常的に使用することは推奨しませんが、特殊なケースでは有用となる場合もあります。 例えば、テーブル内のほとんど全ての行を削除し、そのテーブルによるディスクの使用量を物理的に縮小したい場合です。 VACUUM FULLはたいていの場合、通常のVACUUMよりもテーブルを縮小します。

VACUUMによりI/Oトラフィックがかなり増大しますので、実行中の他のセッションの性能が悪化してしまいます。 このため、コストベースのバキューム遅延機能の使用を推奨する場合があります。 詳細は項17.4.4を参照してください。

下記の例は、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.
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文はありません。

関連項目

vacuumdb, コストに基づくVacuum遅延