PostgreSQL 9.0.0文書
前のページ | 巻戻し |  | 早送り | 次のページ

# VACUUM

## 名前

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

## 概要

    VACUUM [ ( { FULL | FREEZE | VERBOSE | ANALYZE } [, ...] ) ] [ table [ (column [, ...] ) ] ]
    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`では、テーブルの内容全体を新しいディスクファイルに書き換えるため領域が余ることはなく、オペレーティングシステムに未使用の領域を返すことができます。 この形式では、実行速度がかなり低速になります。また、処理中のテーブルに対する排他的ロックが必要になります。

オプションリストが括弧でくくられていた場合、オプションを任意の順序で記述することができます。 括弧がないと、オプションは上で示した通りの順番で指定しなければなりません。 PostgreSQL 9.0より前まででは、括弧がない構文のみがサポートされていました。 新しいオプションはすべて括弧付きの構文でのみサポートされるようになる見込みです。

## パラメータ

`FULL`

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

  This method also requires extra disk space, since it writes a new copy of the table and doesn't release the old copy until the operation is complete. Usually this should only be used when a significant amount of space needs to be reclaimed from within the table. --> またこの方式では、テーブルのコピーを新しく書き出し、操作が終わるまで古いコピーが解放されませんので、余分にディスク領域が必要です、 通常、大きな容量がテーブルから回収されなければなら内場合にのみこれが使用されるはずです。

`FREEZE`

  積極的にタプルの"凍結"を選択します。 `FREEZE`指定は、vacuum_freeze_min_ageパラメータをゼロとして`VACUUM`を実行することと同じです。 `FREEZE`は廃止予定であり、今後のリリースで削除される予定です。 代わりに上記パラメータを設定してください。

`VERBOSE`

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

`ANALYZE`

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

`table`

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

`column`

  解析の対象とする列名です。デフォルトは全列です。 列リストが指定された場合は`ANALYZE`を意味します。

## 出力

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

## 注釈

テーブルをバキュームするためには、通常はテーブルの所有者もしくはスーパーユーザでなければなりません。 しかしデータベースの所有者は共有カタログを除くデータベース内の全テーブルをバキュームすることができます。 （共有カタログに関する制限は、データベース全体の`VACUUM`はスーパーユーザのみが実行可能であることを意味します。） `VACUUM`は、呼び出したユーザがバキュームするための権限を持たないテーブルはすべて飛ばします。

トランザクションブロック内で`VACUUM`を実行することはできません。

GINインデックスを持つテーブルでは、`VACUUM`（全構文）は待ち状態のインデックス挿入を、待ち状態のインデックス構文を主GINインデックス構造内の適切なところに移動させることにより、すべて完了させます。 項53.3.1を参照してください。

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

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

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

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.
    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, 項18.4.3, 項23.1.5

前のページ | ホーム | 次のページ
UPDATE | 上に戻る | VALUES