<productname>PostgreSQL</productname>'s <link linkend="sql-vacuum"><command>VACUUM</command></link> command has to process each table on a regular basis for several reasons: PostgreSQLのVACUUMコマンドは以下の理由により定期的にそれぞれのテーブルを処理しなければなりません。

Each of these reasons dictates performing <command>VACUUM</command> operations of varying frequency and scope, as explained in the following subsections. 以降の小節で説明するように、これらの理由の1つ1つはVACUUM操作の実行について、その頻度の変動や対象領域の変動に影響します。

There are two variants of <command>VACUUM</command>: standard <command>VACUUM</command> and <command>VACUUM FULL</command>. <command>VACUUM FULL</command> can reclaim more disk space but runs much more slowly. Also, the standard form of <command>VACUUM</command> can run in parallel with production database operations. (Commands such as <command>SELECT</command>, <command>INSERT</command>, <command>UPDATE</command>, and <command>DELETE</command> will continue to function normally, though you will not be able to modify the definition of a table with commands such as <command>ALTER TABLE</command> while it is being vacuumed.) <command>VACUUM FULL</command> requires an <literal>ACCESS EXCLUSIVE</literal> lock on the table it is working on, and therefore cannot be done in parallel with other use of the table. Generally, therefore, administrators should strive to use standard <command>VACUUM</command> and avoid <command>VACUUM FULL</command>. VACUUMには、標準VACUUMとVACUUM FULLという２つの種類があります。 VACUUM FULLはより多くのディスク容量を回収することができますが、実行にとても時間がかかります。 また、VACUUMの標準形式は実運用のデータベースに対する操作と同時に実行させることができます。 （SELECT、INSERT、UPDATE、DELETEなどのコマンドは通常通りに動作し続けます。 しかし、バキューム処理中はALTER TABLEなどのコマンドを使用してテーブル定義を変更することはできません。） VACUUM FULLはそれが作用するテーブルに対しACCESS EXCLUSIVEロックを必要とするので、それらテーブルのその他の用途と並行して行うことはできません。 一般的に、管理者は標準VACUUMの使用に努め、VACUUM FULLの使用を避けるべきです。

<command>VACUUM</command> creates a substantial amount of I/O traffic, which can cause poor performance for other active sessions. There are configuration parameters that can be adjusted to reduce the performance impact of background vacuuming &mdash; see <xref linkend="runtime-config-resource-vacuum-cost"/>. VACUUMは、かなりの量のI/Oトラフィックを発生させます。 このため、他の実行中のセッションの性能を劣化させる可能性があります。 バックグラウンドで実行されるバキューム処理による性能への影響を軽減させることを調整できるような設定パラメータがあります。 19.4.4を参照してください。

In <productname>PostgreSQL</productname>, an <command>UPDATE</command> or <command>DELETE</command> of a row does not immediately remove the old version of the row. This approach is necessary to gain the benefits of multiversion concurrency control (<acronym>MVCC</acronym>, see <xref linkend="mvcc"/>): the row version must not be deleted while it is still potentially visible to other transactions. But eventually, an outdated or deleted row version is no longer of interest to any transaction. The space it occupies must then be reclaimed for reuse by new rows, to avoid unbounded growth of disk space requirements. This is done by running <command>VACUUM</command>. PostgreSQLでは、行のUPDATEもしくはDELETEは古い行を即座に削除しません。 この方法は、多版同時性制御（MVCC。第13章を参照してください）の恩恵を受けるために必要なものです。 あるバージョンの行は他のトランザクションから参照される可能性がある場合は削除されてはなりません。 しかし最終的には、更新された前の行や削除された行を参照するトランザクションはなくなります。 必要なディスク容量が無制限に増加しないように、これらが占める領域は、新しい行で再利用できるように回収されなければなりません。 これはVACUUMを実行することで行われます。

The standard form of <command>VACUUM</command> removes dead row versions in tables and indexes and marks the space available for future reuse. However, it will not return the space to the operating system, except in the special case where one or more pages at the end of a table become entirely free and an exclusive table lock can be easily obtained. In contrast, <command>VACUUM FULL</command> actively compacts tables by writing a complete new version of the table file with no dead space. This minimizes the size of the table, but can take a long time. It also requires extra disk space for the new copy of the table, until the operation completes. 標準形式のVACUUMは、テーブルとインデックス内の無効な行バージョンを削除し、その領域を将来の再利用が可能であるものとして記録します。 しかし、その領域をオペレーティングシステムに返却することはありません。 例外として、テーブルの末尾に完全に空のページが存在し、かつそのテーブルの排他ロックが容易に獲得できるような特殊な場合には、その領域を返却します。 対照的にVACUUM FULLは、無効な領域のない全く新しいバージョンのテーブルファイルを書き出すことで、積極的にテーブルを圧縮します。 テーブルの容量を最小化しますが、長い時間がかかる可能性があります。 また操作が終わるまで、テーブルの新しいコピー用に余計なディスク領域を必要とします。

The usual goal of routine vacuuming is to do standard <command>VACUUM</command>s often enough to avoid needing <command>VACUUM FULL</command>. The autovacuum daemon attempts to work this way, and in fact will never issue <command>VACUUM FULL</command>. In this approach, the idea is not to keep tables at their minimum size, but to maintain steady-state usage of disk space: each table occupies space equivalent to its minimum size plus however much space gets used up between vacuum runs. Although <command>VACUUM FULL</command> can be used to shrink a table back to its minimum size and return the disk space to the operating system, there is not much point in this if the table will just grow again in the future. Thus, moderately-frequent standard <command>VACUUM</command> runs are a better approach than infrequent <command>VACUUM FULL</command> runs for maintaining heavily-updated tables. 定常的なバキューム作業の通例の目安はVACUUM FULLの必要性を避けるに充分な頻度で標準VACUUMを行うことです。 自動バキュームデーモンはこのようにして作動を試みます。 そして実際VACUUM FULLを行いません。 この手法において、その発想はテーブルを最小サイズに保つのではなく、ディスク領域使用の安定状態を保持することです。 それぞれのテーブルは、その最小サイズにバキューム作業とバキューム作業の間で使用されることになる容量を加えたのに等しい空間を占有します。 VACUUM FULLは、テーブルをその最小サイズまで縮小し、ディスク空間をオペレーティングシステムに返却するために使用することができますが、もし将来そのテーブルが再び肥大化するのであれば、大した意味がありません。 従って、程よい頻度の標準VACUUMを実行するほうが、不定期のVACUUM FULLを実行するより大量の更新テーブルを保守するにはより良い取り組みとなります。

Some administrators prefer to schedule vacuuming themselves, for example doing all the work at night when load is low. The difficulty with doing vacuuming according to a fixed schedule is that if a table has an unexpected spike in update activity, it may get bloated to the point that <command>VACUUM FULL</command> is really necessary to reclaim space. Using the autovacuum daemon alleviates this problem, since the daemon schedules vacuuming dynamically in response to update activity. It is unwise to disable the daemon completely unless you have an extremely predictable workload. One possible compromise is to set the daemon's parameters so that it will only react to unusually heavy update activity, thus keeping things from getting out of hand, while scheduled <command>VACUUM</command>s are expected to do the bulk of the work when the load is typical. 例えば負荷が少ない夜間に全ての作業を行うように、一部の管理者は自身で計画したバキューム作業の方を選びます。 固定したスケジュールに従ってバキューム作業を行うことについての問題は、もし更新作業によりテーブルが予期せぬ急増に遭遇した場合、空き領域を回収するためにVACUUM FULLが本当に必要となるところまで肥大化することです。 自動バキュームデーモンを使用することにより、この問題は緩和されます。 なぜなら、このデーモンは更新作業に反応して動的にバキューム作業を計画するからです。 完全に作業量を予測することができない限り、デーモンを完全に無効化するのは勧められません。 取り得る妥協案の1つは、いつになく激しい更新作業にのみ反応するよう、デーモンのパラメータを設定することです。 これにより、抑制可能な範囲を維持しつつ、負荷が標準的な場合に計画化されたVACUUMがまとめて作業を行うことを想定することができます。

For those not using autovacuum, a typical approach is to schedule a database-wide <command>VACUUM</command> once a day during a low-usage period, supplemented by more frequent vacuuming of heavily-updated tables as necessary. (Some installations with extremely high update rates vacuum their busiest tables as often as once every few minutes.) If you have multiple databases in a cluster, don't forget to <command>VACUUM</command> each one; the program <xref linkend="app-vacuumdb"/> might be helpful. 自動バキュームを使用しない場合の典型的な方式は、データベース全体のVACUUMを1日1回使用頻度が低い時間帯にスケジュールすることです。 必要に応じて、更新頻度の激しいテーブルのバキューム処理をより頻繁に行うよう追加してください。 （非常に高い頻度でデータの更新を行うインストレーションの中では、分間隔位という頻度で高負荷なテーブルのVACUUMを行うこともあります。） 1つのクラスタで複数のデータベースがある場合、それぞれをバキュームすることを忘れないでください。 vacuumdbプログラムが役に立つかもしれません。

The <productname>PostgreSQL</productname> query planner relies on statistical information about the contents of tables in order to generate good plans for queries. These statistics are gathered by the <link linkend="sql-analyze"><command>ANALYZE</command></link> command, which can be invoked by itself or as an optional step in <command>VACUUM</command>. It is important to have reasonably accurate statistics, otherwise poor choices of plans might degrade database performance. PostgreSQL問い合わせプランナは、優れた問い合わせ計画を作成するのに、テーブルの内容に関する統計情報に依存しています。 この統計情報はANALYZEコマンドによって収集されます。 このコマンドはそのものを呼び出す以外にも、VACUUMのオプション処理としても呼び出すことができます。 合理的な精度の統計情報を持つことは重要です。 さもないと非効率的な計画を選択してしまい、データベースの性能を悪化させてしまいます。

The autovacuum daemon, if enabled, will automatically issue <command>ANALYZE</command> commands whenever the content of a table has changed sufficiently. However, administrators might prefer to rely on manually-scheduled <command>ANALYZE</command> operations, particularly if it is known that update activity on a table will not affect the statistics of <quote>interesting</quote> columns. The daemon schedules <command>ANALYZE</command> strictly as a function of the number of rows inserted or updated; it has no knowledge of whether that will lead to meaningful statistical changes. 自動バキュームデーモンが有効になっている場合は、テーブルの内容が大きく変更されたときはいつでも自動的にANALYZEコマンドを発行します。 しかし、特にテーブルの更新作業が「興味のある」列の統計情報に影響を与えないことが判っている時、手作業により計画されたANALYZE操作を当てにする方が好ましいと管理者は思うかもしれません。 デーモンは、挿入または更新された行数の関数としてANALYZEを厳密に計画します。 しかし、意味のある統計情報の変更につながるかどうかは判りません。

Tuples changed in partitions and inheritance children do not trigger analyze on the parent table. If the parent table is empty or rarely changed, it may never be processed by autovacuum, and the statistics for the inheritance tree as a whole won't be collected. It is necessary to run <command>ANALYZE</command> on the parent table manually in order to keep the statistics up to date. パーティションや継承の子で変更されたタプルは親テーブルでの解析を誘発しません。 親テーブルが空であったり、まれにしか変更されなかったりする場合、自動バキュームにより処理されることはなく、継承ツリー全体としての統計情報は収集されないかもしれません。 統計情報を最新に保つためには、親テーブルでANALYZEを手動で実行することが必要です。

As with vacuuming for space recovery, frequent updates of statistics are more useful for heavily-updated tables than for seldom-updated ones. But even for a heavily-updated table, there might be no need for statistics updates if the statistical distribution of the data is not changing much. A simple rule of thumb is to think about how much the minimum and maximum values of the columns in the table change. For example, a <type>timestamp</type> column that contains the time of row update will have a constantly-increasing maximum value as rows are added and updated; such a column will probably need more frequent statistics updates than, say, a column containing URLs for pages accessed on a website. The URL column might receive changes just as often, but the statistical distribution of its values probably changes relatively slowly. 領域復旧のためのバキューム処理と同様、頻繁な統計情報の更新は、滅多に更新されないテーブルよりも更新の激しいテーブルにとってより有益です。 しかし、頻繁に更新されるテーブルであっても、データの統計的な分布が大きく変更されなければ、統計情報を更新する必要はありません。 単純な鉄則は、テーブル内の列の最小値、最大値にどのくらいの変化があったかを考えることです。 例えば、行の更新時刻を保持するtimestamp列の場合、最大値は行が追加、更新されるにつれて、単純に増加します。 こういった列は、おそらく、例えば、あるWebサイト上のアクセスされたページのURLを保持する列よりも頻繁に統計情報を更新する必要があるでしょう。 このURL列の更新頻度も高いものかもしれませんが、その値の統計的な分布の変更は相対的に見ておそらく低いものです。

It is possible to run <command>ANALYZE</command> on specific tables and even just specific columns of a table, so the flexibility exists to update some statistics more frequently than others if your application requires it. In practice, however, it is usually best to just analyze the entire database, because it is a fast operation. <command>ANALYZE</command> uses a statistically random sampling of the rows of a table rather than reading every single row. 特定のテーブルに対してANALYZEを実行することができます。 また、テーブルの特定の列のみに対してさえも実行することができます。 ですので、アプリケーションの要求に応じて、他よりも頻繁に一部の統計情報を更新できるような柔軟性があります。 しかし、実際には、操作が高速であるため、単にデータベース全体を解析することが最善です。 ANALYZEは、すべての行を読むのではなく、テーブルから統計的にランダムな行を抽出して使用します。

Vacuum maintains a <link linkend="storage-vm">visibility map</link> for each table to keep track of which pages contain only tuples that are known to be visible to all active transactions (and all future transactions, until the page is again modified). This has two purposes. First, vacuum itself can skip such pages on the next run, since there is nothing to clean up. バキュームは、どのページにすべての有効トランザクション（およびページが再度更新されるまでの将来のトランザクション）で可視であることが分かっているタプルのみが含まれるかを追跡するために、各テーブルの可視性マップの保守を行います。 ２つの目的があります。 １つ目はバキューム自身が、整理するものがありませんので、こうしたページを次回飛ばすことができます。

Second, it allows <productname>PostgreSQL</productname> to answer some queries using only the index, without reference to the underlying table. Since <productname>PostgreSQL</productname> indexes don't contain tuple visibility information, a normal index scan fetches the heap tuple for each matching index entry, to check whether it should be seen by the current transaction. An <link linkend="indexes-index-only-scans"><firstterm>index-only scan</firstterm></link>, on the other hand, checks the visibility map first. If it's known that all tuples on the page are visible, the heap fetch can be skipped. This is most useful on large data sets where the visibility map can prevent disk accesses. The visibility map is vastly smaller than the heap, so it can easily be cached even when the heap is very large. ２つ目は、PostgreSQLが、背後にあるテーブルを参照することなく、インデックスのみを使用して一部の問い合わせに応えることができるようになります。 PostgreSQLのインデックスにはタプルの可視性に関する情報を持ちませんので、通常のインデックススキャンは合致したインデックス項目のヒープタプルを取り込み、現在のトランザクションから可視であるべきかどうか検査します。 一方でインデックスオンリースキャンはまず可視性マップを検査します。 そのページのタプルがすべて可視であることが分かれば、ヒープの取り出しを省くことができます。 可視性マップによりディスクアクセスを防ぐことができる大規模なデータ群に対して、特に有効です。 可視性マップはヒープより非常に小さいため、ヒープが非常に大きい場合であっても簡単にキャッシュすることができます。

<productname>PostgreSQL</productname>'s <link linkend="mvcc-intro">MVCC</link> transaction semantics depend on being able to compare transaction ID (<acronym>XID</acronym>) numbers: a row version with an insertion XID greater than the current transaction's XID is <quote>in the future</quote> and should not be visible to the current transaction. But since transaction IDs have limited size (32 bits) a cluster that runs for a long time (more than 4 billion transactions) would suffer <firstterm>transaction ID wraparound</firstterm>: the XID counter wraps around to zero, and all of a sudden transactions that were in the past appear to be in the future &mdash; which means their output become invisible. In short, catastrophic data loss. (Actually the data is still there, but that's cold comfort if you cannot get at it.) To avoid this, it is necessary to vacuum every table in every database at least once every two billion transactions. PostgreSQLのMVCCトランザクションのセマンティクスは、トランザクションID（XID）番号の比較が可能であることに依存しています。 現在のトランザクションのXIDよりも新しい挿入時のXIDを持ったバージョンの行は、「未来のもの」であり、現在のトランザクションから可視であってはなりません。 しかし、トランザクションIDのサイズには制限（32ビット）があり、長時間（40億トランザクション）稼働しているクラスタはトランザクションの周回を経験します。 XIDのカウンタが一周して0に戻り、そして、突然に、過去になされたトランザクションが将来のものと見えるように、つまり、その出力が不可視になります。 端的に言うと、破滅的なデータの損失です。 （実際はデータは保持されていますが、それを入手することができなければ、慰めにならないでしょう。） これを防ぐためには、すべてのデータベースにあるすべてのテーブルを少なくとも20億トランザクションごとにバキュームする必要があります。

The reason that periodic vacuuming solves the problem is that <command>VACUUM</command> will mark rows as <emphasis>frozen</emphasis>, indicating that they were inserted by a transaction that committed sufficiently far in the past that the effects of the inserting transaction are certain to be visible to all current and future transactions. Normal XIDs are compared using modulo-2<superscript>32</superscript> arithmetic. This means that for every normal XID, there are two billion XIDs that are <quote>older</quote> and two billion that are <quote>newer</quote>; another way to say it is that the normal XID space is circular with no endpoint. Therefore, once a row version has been created with a particular normal XID, the row version will appear to be <quote>in the past</quote> for the next two billion transactions, no matter which normal XID we are talking about. If the row version still exists after more than two billion transactions, it will suddenly appear to be in the future. To prevent this, <productname>PostgreSQL</productname> reserves a special XID, <literal>FrozenTransactionId</literal>, which does not follow the normal XID comparison rules and is always considered older than every normal XID. Frozen row versions are treated as if the inserting XID were <literal>FrozenTransactionId</literal>, so that they will appear to be <quote>in the past</quote> to all normal transactions regardless of wraparound issues, and so such row versions will be valid until deleted, no matter how long that is. 定期的なバキューム処理によりこの問題が解決する理由は、VACUUMが行に凍結状態という印をつけて、挿入トランザクションの効果が確実に可視になるような十分遠い過去にコミットされたトランザクションによりそれらが挿入されたことを表すからです。 PostgreSQLは特別なXID、FrozenTransactionIdを確保します。 このXIDは通常のXIDの比較規則には従わず、常に全ての通常のXIDよりも古いものとみなされます。 通常のXID（2以上の値）はmodulo-2³²という数式を使用して比較されます。 これは、全ての通常のXIDでは、20億の「より古い」XIDと20億の「より新しい」XIDが存在することを意味します。 言い換えると、通常のXID空間は終わることなく循環されているということです。 そのため、ある特定のXIDであるバージョンの行を作成すると、そのバージョンの行は、以降の20億トランザクションからはどの通常のXIDについて比較しているのかには関係なく、 「過去のもの」と認識されます。 そのバージョンの行が20億トランザクション以上後にも存在していた場合、それは突然に未来のものとして認識されます。 これを防ぐために、凍結された行バージョンは挿入XIDがFrozenTransactionIdであるかのように扱われ、それで、周回問題に関係なく、すべての通常のトランザクションから「過去のもの」として認識され、また、そのバージョンの行はどれだけ古いものであろうと、削除されるまで有効状態となります。

<xref linkend="guc-vacuum-freeze-min-age"/> controls how old an XID value has to be before rows bearing that XID will be frozen. Increasing this setting may avoid unnecessary work if the rows that would otherwise be frozen will soon be modified again, but decreasing this setting increases the number of transactions that can elapse before the table must be vacuumed again. vacuum_freeze_min_ageは、その行バージョンが凍結される前に、XID値がどのくらい経過しているのかを制御します。 この設定値を大きくすることで、そうでなければ凍結状態になる行がすぐに再び修正されるのであれば、不必要な作業を避けられるかもしれませんが、この設定値を小さくすることでテーブルを次にバキュームする必要が起こるまで継続できるトランザクション数が増加します。

<command>VACUUM</command> uses the <link linkend="storage-vm">visibility map</link> to determine which pages of a table must be scanned. Normally, it will skip pages that don't have any dead row versions even if those pages might still have row versions with old XID values. Therefore, normal <command>VACUUM</command>s won't always freeze every old row version in the table. When that happens, <command>VACUUM</command> will eventually need to perform an <firstterm>aggressive vacuum</firstterm>, which will freeze all eligible unfrozen XID and MXID values, including those from all-visible but not all-frozen pages. In practice most tables require periodic aggressive vacuuming. <xref linkend="guc-vacuum-freeze-table-age"/> controls when <command>VACUUM</command> does that: all-visible but not all-frozen pages are scanned if the number of transactions that have passed since the last such scan is greater than <varname>vacuum_freeze_table_age</varname> minus <varname>vacuum_freeze_min_age</varname>. Setting <varname>vacuum_freeze_table_age</varname> to 0 forces <command>VACUUM</command> to always use its aggressive strategy. VACUUMは可視性マップを使用して、テーブルのどのページを走査する必要があるかを決定します。 通常は、無効な行バージョンを持っていないページをスキップします。このとき、そのページに古いXID値の行バージョンがまだある可能性があったとしても読み飛ばします。 したがって、通常のVACUUMでは必ずしもテーブル内のすべての古い行バージョンを凍結するわけではありません。 そのようなことが起きた場合には、最終的にVACUUMで積極的なバキュームを実行する必要があるでしょう。そのときは、全可視ではあるが全凍結ではないページにあるものを含めて、適切な凍結されていないXID値やMXID値をすべて凍結します。 実際には、ほとんどのテーブルには定期的な積極的なバキュームが必要です。 vacuum_freeze_table_ageはVACUUMがいつこれを行うかを制御します。 つまり、最後にそのような走査が行われた後に実行されたトランザクションの数がvacuum_freeze_table_ageからvacuum_freeze_min_ageを引いた数より大きいとき、全可視ではあるが全凍結ではないページも走査されます。 vacuum_freeze_table_ageを0に設定するとVACUUMは常にこの積極的な戦略を使うようになります。

The maximum time that a table can go unvacuumed is two billion transactions minus the <varname>vacuum_freeze_min_age</varname> value at the time of the last aggressive vacuum. If it were to go unvacuumed for longer than that, data loss could result. To ensure that this does not happen, autovacuum is invoked on any table that might contain unfrozen rows with XIDs older than the age specified by the configuration parameter <xref linkend="guc-autovacuum-freeze-max-age"/>. (This will happen even if autovacuum is disabled.) テーブルをバキュームすることなく処理できる最大の時間は、20億トランザクションから最後に積極的なバキュームを実行した時点のvacuum_freeze_min_ageの値を差し引いたものです。 この時間よりも長期間バキュームを行わないと、データ損失が発生するかもしれません。 これを確実に防止するために、自動バキュームがautovacuum_freeze_max_age設定パラメータで指定された時代より古いXIDを持つ、凍結状態でない行を含む可能性がある任意のテーブルに対して呼び出されます。 （これは自動バキュームが無効であっても起こります。）

This implies that if a table is not otherwise vacuumed, autovacuum will be invoked on it approximately once every <varname>autovacuum_freeze_max_age</varname> minus <varname>vacuum_freeze_min_age</varname> transactions. For tables that are regularly vacuumed for space reclamation purposes, this is of little importance. However, for static tables (including tables that receive inserts, but no updates or deletes), there is no need to vacuum for space reclamation, so it can be useful to try to maximize the interval between forced autovacuums on very large static tables. Obviously one can do this either by increasing <varname>autovacuum_freeze_max_age</varname> or decreasing <varname>vacuum_freeze_min_age</varname>. これは、あるテーブルがバキュームされていなかったとしても、自動バキュームがおよそautovacuum_freeze_max_age - vacuum_freeze_min_ageトランザクション毎に呼び出されることを意味します。 領域確保のために定常的にバキューム処理を行うテーブルでは、これは重要ではありません。 しかし、（挿入のみで更新や削除が行われないテーブルを含む）静的なテーブルでは、領域確保のためのバキューム処理を行う必要がなくなりますので、非常に長期間静的なテーブルでは、強制的な自動バキューム間の間隔を最大まで延ばすことができます。 記載するまでもありませんが、autovacuum_freeze_max_ageを増やすことでもvacuum_freeze_min_ageを減らすことでも、これを行うことができます。

The effective maximum for <varname>vacuum_freeze_table_age</varname> is 0.95 * <varname>autovacuum_freeze_max_age</varname>; a setting higher than that will be capped to the maximum. A value higher than <varname>autovacuum_freeze_max_age</varname> wouldn't make sense because an anti-wraparound autovacuum would be triggered at that point anyway, and the 0.95 multiplier leaves some breathing room to run a manual <command>VACUUM</command> before that happens. As a rule of thumb, <command>vacuum_freeze_table_age</command> should be set to a value somewhat below <varname>autovacuum_freeze_max_age</varname>, leaving enough gap so that a regularly scheduled <command>VACUUM</command> or an autovacuum triggered by normal delete and update activity is run in that window. Setting it too close could lead to anti-wraparound autovacuums, even though the table was recently vacuumed to reclaim space, whereas lower values lead to more frequent aggressive vacuuming. vacuum_freeze_table_ageに対する有効な最大値は0.95 * autovacuum_freeze_max_ageです。 これより値が高いと値は最大値までに制限されます。 autovacuum_freeze_max_ageより高い値は、周回防止用の自動バキュームがその時点でいずれにせよ誘発され、0.95という乗算係数がそれが起こる前に手動によるVACUUM実行の余地を残すため、意味を持ちません。 経験則に従うと、定期的に計画されたVACUUMもしくは通常の削除・更新作業により誘発された自動バキュームがその期間で実行されるように十分な間隔を残しておくように、vacuum_freeze_table_ageはautovacuum_freeze_max_ageより多少低い値に設定されるべきです。 これを余りにも近い値に設定すると、たとえ領域を回収するために最近テーブルがバキュームされたとしても、周回防止用の自動バキュームに帰着します。 一方より低い値はより頻繁な積極的バキュームを引き起こします。

The sole disadvantage of increasing <varname>autovacuum_freeze_max_age</varname> (and <varname>vacuum_freeze_table_age</varname> along with it) is that the <filename>pg_xact</filename> and <filename>pg_commit_ts</filename> subdirectories of the database cluster will take more space, because it must store the commit status and (if <varname>track_commit_timestamp</varname> is enabled) timestamp of all transactions back to the <varname>autovacuum_freeze_max_age</varname> horizon. The commit status uses two bits per transaction, so if <varname>autovacuum_freeze_max_age</varname> is set to its maximum allowed value of two billion, <filename>pg_xact</filename> can be expected to grow to about half a gigabyte and <filename>pg_commit_ts</filename> to about 20GB. If this is trivial compared to your total database size, setting <varname>autovacuum_freeze_max_age</varname> to its maximum allowed value is recommended. Otherwise, set it depending on what you are willing to allow for <filename>pg_xact</filename> and <filename>pg_commit_ts</filename> storage. (The default, 200 million transactions, translates to about 50MB of <filename>pg_xact</filename> storage and about 2GB of <filename>pg_commit_ts</filename> storage.) autovacuum_freeze_max_age（およびそれに付随するvacuum_freeze_table_age）を増やす唯一の欠点は、データベースクラスタのサブディレクトリpg_xactとpg_commit_tsがより大きな容量となることです。 autovacuum_freeze_max_ageの範囲まですべてのトランザクションのコミット状況と(track_commit_timestampが指定されていれば)タイムスタンプを格納しなければならないためです。 コミット状況は1トランザクション当たり2ビット使用しますので、もしautovacuum_freeze_max_ageをその最大許容値である20億に設定している場合、pg_xactはおよそ0.5ギガバイトまで、pg_commit_tsは約20GBまで膨らむものと考えられます。 これがデータベースサイズ全体に対してとるに足らないものであれば、autovacuum_freeze_max_ageを最大許容値に設定することを勧めます。 さもなければ、pg_xactとpg_commit_tsの容量として許容できる値に応じてそれらを設定してください。 （デフォルトは2億トランザクションです。換算するとpg_xactはおよそ50MB、pg_commit_tsはおよそ2GBの容量となります。）

One disadvantage of decreasing <varname>vacuum_freeze_min_age</varname> is that it might cause <command>VACUUM</command> to do useless work: freezing a row version is a waste of time if the row is modified soon thereafter (causing it to acquire a new XID). So the setting should be large enough that rows are not frozen until they are unlikely to change any more. vacuum_freeze_min_age を減らすことにも1つ欠点があります。 これによりVACUUMが大して役に立たなくなるかもしれません。 テーブル行がすぐに変更される場合（新しいXIDを獲得することになります）、行バージョンを凍結することは時間の無駄です。 そのため、この設定は、行の変更が起こらなくなるまで凍結されない程度に大きくすべきです。

To track the age of the oldest unfrozen XIDs in a database, <command>VACUUM</command> stores XID statistics in the system tables <structname>pg_class</structname> and <structname>pg_database</structname>. In particular, the <structfield>relfrozenxid</structfield> column of a table's <structname>pg_class</structname> row contains the oldest remaining unfrozen XID at the end of the most recent <command>VACUUM</command> that successfully advanced <structfield>relfrozenxid</structfield> (typically the most recent aggressive VACUUM). Similarly, the <structfield>datfrozenxid</structfield> column of a database's <structname>pg_database</structname> row is a lower bound on the unfrozen XIDs appearing in that database &mdash; it is just the minimum of the per-table <structfield>relfrozenxid</structfield> values within the database. A convenient way to examine this information is to execute queries such as: データベース内のもっとも古い凍結されていないXIDの年代を追跡するために、VACUUMはシステムテーブルpg_classとpg_databaseにXID統計情報を保持します。 特に、テーブルに対応するpg_class行のrelfrozenxid列には、relfrozenxidを進めることに成功した最後のVACUUM（典型的には最後の積極的なVACUUM）の終わりに残っているもっとも古い凍結されていないXIDが含まれます。 同様に、データベースに対応するpg_database行のdatfrozenxid列は、データベース内で現れる凍結されていないXIDの下限値です。 これは、そのデータベース内のテーブル当たりのrelfrozenxid値の最小値です。 この情報を検査する簡便な方法は、以下の問い合わせを実行することです。

SELECT c.oid::regclass as table_name,
       greatest(age(c.relfrozenxid),age(t.relfrozenxid)) as age
FROM pg_class c
LEFT JOIN pg_class t ON c.reltoastrelid = t.oid
WHERE c.relkind IN ('r', 'm');

SELECT datname, age(datfrozenxid) FROM pg_database;

The <literal>age</literal> column measures the number of transactions from the cutoff XID to the current transaction's XID. age列は切り捨てXIDから現在のトランザクションXIDまでのトランザクション数を測ります。

<command>VACUUM</command> normally only scans pages that have been modified since the last vacuum, but <structfield>relfrozenxid</structfield> can only be advanced when every page of the table that might contain unfrozen XIDs is scanned. This happens when <structfield>relfrozenxid</structfield> is more than <varname>vacuum_freeze_table_age</varname> transactions old, when <command>VACUUM</command>'s <literal>FREEZE</literal> option is used, or when all pages that are not already all-frozen happen to require vacuuming to remove dead row versions. When <command>VACUUM</command> scans every page in the table that is not already all-frozen, it should set <literal>age(relfrozenxid)</literal> to a value just a little more than the <varname>vacuum_freeze_min_age</varname> setting that was used (more by the number of transactions started since the <command>VACUUM</command> started). <command>VACUUM</command> will set <structfield>relfrozenxid</structfield> to the oldest XID that remains in the table, so it's possible that the final value will be much more recent than strictly required. If no <structfield>relfrozenxid</structfield>-advancing <command>VACUUM</command> is issued on the table until <varname>autovacuum_freeze_max_age</varname> is reached, an autovacuum will soon be forced for the table. VACUUMは通常は最後のバキュームの後で変更されたページのみ走査しますが、relfrozenxidはテーブルの凍結されていないXIDを含むかもしれないすべてのページを走査したときのみ繰り上がります。 これは、relfrozenxidがvacuum_freeze_table_ageトランザクション年齢より大きい時、VACUUMのFREEZEオプションが使用された時、もしくは無効な行バージョンを削除するため全凍結になっていないすべてのページをバキュームしなければならなくなった時に発生します。 VACUUMがテーブルの全凍結になっていないすべてのページを走査したとき、age(relfrozenxid)は、使用されたvacuum_freeze_min_age設定より若干大きくなるはずです （VACUUMを起動してから始まったトランザクションの数分大きくなります）。 VACUUMはrelfrozenxidをテーブルに残っている最も古いXIDに設定しますので、最後の値を厳密に要求されるものよりずっとより新しいものとすることが可能です。 relfrozenxidを繰り上げるVACUUMがautovacuum_freeze_max_ageに達するまでにテーブルに対して発行されない場合、そのテーブルに対して自動バキュームが早急に強制されます。

If for some reason autovacuum fails to clear old XIDs from a table, the system will begin to emit warning messages like this when the database's oldest XIDs reach forty million transactions from the wraparound point: 何らかの理由により自動バキュームがテーブルの古いXIDの整理に失敗した場合、システムはデータベースの最古のXIDが周回ポイントから4000万トランザクションに達した場合と似たような警告メッセージを発行し始めます。

WARNING:  database "mydb" must be vacuumed within 39985967 transactions
HINT:  To avoid XID assignment failures, execute a database-wide VACUUM in that database.

(A manual <command>VACUUM</command> should fix the problem, as suggested by the hint; but note that the <command>VACUUM</command> should be performed by a superuser, else it will fail to process system catalogs, which prevent it from being able to advance the database's <structfield>datfrozenxid</structfield>.) If these warnings are ignored, the system will refuse to assign new XIDs once there are fewer than three million transactions left until wraparound: （ヒントで示唆されたように手動VACUUMはこの問題を解決します。 しかし、VACUUMはスーパーユーザで実行されるべきであること注意してください。 さもないとシステムカタログの処理に失敗し、このためデータベースのdatfrozenxidを繰り上げることができません。） こうした警告も無視し続け、周回するまでのトランザクションが300万より少なくなると、システムは新しいXIDの割り当てを拒絶します。

ERROR:  database is not accepting commands that assign new XIDs to avoid wraparound data loss in database "mydb"
HINT:  Execute a database-wide VACUUM in that database.

In this condition any transactions already in progress can continue, but only read-only transactions can be started. Operations that modify database records or truncate relations will fail. The <command>VACUUM</command> command can still be run normally. Note that, contrary to what was sometimes recommended in earlier releases, it is not necessary or desirable to stop the postmaster or enter single user-mode in order to restore normal operation. Instead, follow these steps: この状態では、すでに進行中のトランザクションは継続できますが、読み込み専用トランザクションのみを開始できます。 データベースレコードを変更したり、リレーションを切り詰めたりする操作は失敗します。 VACUUMコマンドは通常どおりに実行できます。 以前のリリースで推奨されていたことに反して、通常の操作を復元するために、postmasterを停止したりシングルユーザモードに入ったりする必要はなく、また、それが望ましいことでもないことに注意してください。 代わりに、次の手順を実行してください。

<productname>PostgreSQL</productname> has an optional but highly recommended feature called <firstterm>autovacuum</firstterm>, whose purpose is to automate the execution of <command>VACUUM</command> and <command>ANALYZE</command> commands. When enabled, autovacuum checks for tables that have had a large number of inserted, updated or deleted tuples. These checks use the statistics collection facility; therefore, autovacuum cannot be used unless <xref linkend="guc-track-counts"/> is set to <literal>true</literal>. In the default configuration, autovacuuming is enabled and the related configuration parameters are appropriately set. PostgreSQLには、省略可能ですが強く推奨される自動バキュームという機能があります。 これはVACUUMとANALYZEコマンドの実行を自動化することを目的としたものです。 有効にすると、自動バキュームは大量のタプルの挿入、更新、削除があったテーブルを検査します。 この検査は統計情報収集機能を使用します。 したがって、track_countsがtrueに設定されていないと、自動バキュームを使用することができません。 デフォルトの設定では、自動バキュームは有効で、関連するパラメータも適切に設定されています。

The <quote>autovacuum daemon</quote> actually consists of multiple processes. There is a persistent daemon process, called the <firstterm>autovacuum launcher</firstterm>, which is in charge of starting <firstterm>autovacuum worker</firstterm> processes for all databases. The launcher will distribute the work across time, attempting to start one worker within each database every <xref linkend="guc-autovacuum-naptime"/> seconds. (Therefore, if the installation has <replaceable>N</replaceable> databases, a new worker will be launched every <varname>autovacuum_naptime</varname>/<replaceable>N</replaceable> seconds.) A maximum of <xref linkend="guc-autovacuum-max-workers"/> worker processes are allowed to run at the same time. If there are more than <varname>autovacuum_max_workers</varname> databases to be processed, the next database will be processed as soon as the first worker finishes. Each worker process will check each table within its database and execute <command>VACUUM</command> and/or <command>ANALYZE</command> as needed. <xref linkend="guc-log-autovacuum-min-duration"/> can be set to monitor autovacuum workers' activity. 実際のところ「自動バキュームデーモン」は複数のプロセスから構成されます。 自動バキュームランチャという永続的デーモンプロセスが存在し、自動バキュームワーカープロセスがすべてのデータベースを処理します。 ランチャは、1つのワーカーを各データベースに対しautovacuum_naptime秒ごとに開始するよう試みることにより、時間に対して作業を分散化します。 （したがってインストレーションにN個のデータベースがある場合、新規ワーカーがautovacuum_naptime/N秒毎に起動されます。） 同時に最大autovacuum_max_workers個のプロセスが実行可能です。 処理対象のデータベースがautovacuum_max_workersより多くある場合、次のデータベースは最初のワーカーが終了するとすぐに処理されます。 それぞれのワーカープロセスはデータベース内の各テーブルを検査し、必要に応じてVACUUMまたはANALYZEコマンドを発行します。 log_autovacuum_min_durationも自動バキュームワーカーの活動を監視するために設定できます。

If several large tables all become eligible for vacuuming in a short amount of time, all autovacuum workers might become occupied with vacuuming those tables for a long period. This would result in other tables and databases not being vacuumed until a worker becomes available. There is no limit on how many workers might be in a single database, but workers do try to avoid repeating work that has already been done by other workers. Note that the number of running workers does not count towards <xref linkend="guc-max-connections"/> or <xref linkend="guc-superuser-reserved-connections"/> limits. 短期間にいくつかの大規模なテーブルがすべてバキューム対象として適切な状態になったとすると、すべての自動バキュームワーカーはこうしたテーブルに対するバキューム処理に長い期間占領される可能性があります。 これにより、ワーカーが利用できるようになるまで、他のテーブルやデータベースに対するバキュームが行われなくなります。 また、単一データベースに対するワーカー数には制限はありませんが、ワーカーはすでに他のワーカーによって実行された作業を繰り返さないように試みます。 ワーカーの実行数はmax_connections制限にもsuperuser_reserved_connections制限にも計上されないことに注意してください。

Tables whose <structfield>relfrozenxid</structfield> value is more than <xref linkend="guc-autovacuum-freeze-max-age"/> transactions old are always vacuumed (this also applies to those tables whose freeze max age has been modified via storage parameters; see below). Otherwise, if the number of tuples obsoleted since the last <command>VACUUM</command> exceeds the <quote>vacuum threshold</quote>, the table is vacuumed. The vacuum threshold is defined as: テーブルのrelfrozenxid値がautovacuum_freeze_max_ageトランザクション年齢よりも古い場合、そのテーブルは常にバキュームされます （これはfreeze max ageがストレージパラメータにより変更されたテーブルに対しても適用されます。以下を参照）。 さもなければ、直前のVACUUMの後に不要となったタプル数が「バキューム閾値」を超えると、テーブルはバキュームされます。 このバキューム閾値は以下のように定義されます。

vacuum threshold = vacuum base threshold + vacuum scale factor * number of tuples

バキューム閾値 = バキューム基礎閾値 + バキューム規模係数 * タプル数

where the vacuum base threshold is <xref linkend="guc-autovacuum-vacuum-threshold"/>, the vacuum scale factor is <xref linkend="guc-autovacuum-vacuum-scale-factor"/>, and the number of tuples is <structname>pg_class</structname>.<structfield>reltuples</structfield>. ここで、バキューム基礎閾値はautovacuum_vacuum_threshold、バキューム規模係数はautovacuum_vacuum_scale_factor、タプル数はpg_class.reltuplesです。

The table is also vacuumed if the number of tuples inserted since the last vacuum has exceeded the defined insert threshold, which is defined as: 直前のバキュームの後に挿入されたタプル数が定義された挿入閾値を超えた場合も、テーブルはバキュームされます。ここで挿入閾値は以下のように定義されます。

vacuum insert threshold = vacuum base insert threshold + vacuum insert scale factor * number of tuples

バキューム挿入閾値 = バキューム基礎挿入閾値 + バキューム挿入規模係数 * タプル数

where the vacuum insert base threshold is <xref linkend="guc-autovacuum-vacuum-insert-threshold"/>, and vacuum insert scale factor is <xref linkend="guc-autovacuum-vacuum-insert-scale-factor"/>. Such vacuums may allow portions of the table to be marked as <firstterm>all visible</firstterm> and also allow tuples to be frozen, which can reduce the work required in subsequent vacuums. For tables which receive <command>INSERT</command> operations but no or almost no <command>UPDATE</command>/<command>DELETE</command> operations, it may be beneficial to lower the table's <xref linkend="reloption-autovacuum-freeze-min-age"/> as this may allow tuples to be frozen by earlier vacuums. The number of obsolete tuples and the number of inserted tuples are obtained from the cumulative statistics system; it is an eventually-consistent count updated by each <command>UPDATE</command>, <command>DELETE</command> and <command>INSERT</command> operation. If the <structfield>relfrozenxid</structfield> value of the table is more than <varname>vacuum_freeze_table_age</varname> transactions old, an aggressive vacuum is performed to freeze old tuples and advance <structfield>relfrozenxid</structfield>; otherwise, only pages that have been modified since the last vacuum are scanned. ここで、バキューム挿入基礎閾値はautovacuum_vacuum_insert_threshold、バキューム挿入規模係数はautovacuum_vacuum_insert_scale_factorです。 そのようなバキュームは、テーブルの一部を全可視と印づけたり、タプルを凍結したりもできますので、後続のバキュームで必要となる作業を減らせます。 より早いバキュームによりタプルを凍結できますので、INSERT操作を受けたもののUPDATE/DELETE操作を全くもしくはほとんど受けていないテーブルに対しては、テーブルのautovacuum_freeze_min_ageを低くすることが有益な場合があります。 不要となったタプル数と挿入されたタプル数は、累積統計情報システムから取得されます。 これは、UPDATE、DELETEおよびINSERT操作ごとに更新される、最終的には一貫性のある数です。 テーブルのrelfrozenxid値がvacuum_freeze_table_ageトランザクション年齢より大きい場合、古いタプルを凍結して、relfrozenxidを繰り上げるため、積極的なバキュームが実行されます。 そうでなければ最後のバキュームの後に変更されたページのみ走査されます。

For analyze, a similar condition is used: the threshold, defined as: 解析でも似たような条件が使用されます。 以下で定義される閾値が、

analyze threshold = analyze base threshold + analyze scale factor * number of tuples

解析閾値 = 解析基礎閾値 + 解析規模係数 * タプル数

is compared to the total number of tuples inserted, updated, or deleted since the last <command>ANALYZE</command>. 前回のANALYZEの後に挿入、更新、削除されたタプル数と比較されます。

Partitioned tables do not directly store tuples and consequently are not processed by autovacuum. (Autovacuum does process table partitions just like other tables.) Unfortunately, this means that autovacuum does not run <command>ANALYZE</command> on partitioned tables, and this can cause suboptimal plans for queries that reference partitioned table statistics. You can work around this problem by manually running <command>ANALYZE</command> on partitioned tables when they are first populated, and again whenever the distribution of data in their partitions changes significantly. パーティション化テーブルはタプルを直接格納しないため、自動バキュームによって処理されません。 (自動バキュームは他のテーブルと同様にテーブルパーティションを処理します。) 残念ながら、これは自動バキュームがパーティション化テーブルでANALYZEを実行しないことを意味し、これによりパーティション化テーブルの統計を参照する問い合わせに対して最適でない計画を生成する可能性があります。 この問題を回避するには、パーティション化テーブルに最初にデータが移入されたときにANALYZEを手動で実行し、パーティション内のデータの分布が大きく変化した場合には必ず再度実行します。

Temporary tables cannot be accessed by autovacuum. Therefore, appropriate vacuum and analyze operations should be performed via session SQL commands. 一時テーブルには自動バキュームでアクセスすることはできません。 したがってセッションのSQLコマンドを用いて適切なバキュームおよび解析操作を行わなければなりません。

The default thresholds and scale factors are taken from <filename>postgresql.conf</filename>, but it is possible to override them (and many other autovacuum control parameters) on a per-table basis; see <xref linkend="sql-createtable-storage-parameters"/> for more information. If a setting has been changed via a table's storage parameters, that value is used when processing that table; otherwise the global settings are used. See <xref linkend="runtime-config-autovacuum"/> for more details on the global settings. デフォルトの閾値と規模係数は、postgresql.confから取られますが、(他の多くの自動バキューム制御パラメータと合わせて)テーブル毎に上書きすることができます。 より詳細な情報は格納パラメータを参照してください。 テーブルのストレージパラメータで設定が変更されると、そのテーブルを処理する時にその値が使用されます。 そうでなければ、全体設定が使われます。 全体設定についての詳細な情報は19.10を参照してください。

When multiple workers are running, the autovacuum cost delay parameters (see <xref linkend="runtime-config-resource-vacuum-cost"/>) are <quote>balanced</quote> among all the running workers, so that the total I/O impact on the system is the same regardless of the number of workers actually running. However, any workers processing tables whose per-table <literal>autovacuum_vacuum_cost_delay</literal> or <literal>autovacuum_vacuum_cost_limit</literal> storage parameters have been set are not considered in the balancing algorithm. 複数のワーカープロセスが実行している場合、自動バキュームコスト遅延パラメータ(19.4.4を参照してください)は実行中のワーカー全体に「振り分け」られます。 このため、ワーカーの実稼働数に関らず、システムに与えるI/Oの総影響は変わりありません。 しかし、テーブル毎のautovacuum_vacuum_cost_delayまたはautovacuum_vacuum_cost_limitストレージパラメータが設定されたテーブルを処理するワーカーは振り分けアルゴリズムでは考慮されません。

Autovacuum workers generally don't block other commands. If a process attempts to acquire a lock that conflicts with the <literal>SHARE UPDATE EXCLUSIVE</literal> lock held by autovacuum, lock acquisition will interrupt the autovacuum. For conflicting lock modes, see <xref linkend="table-lock-compatibility"/>. However, if the autovacuum is running to prevent transaction ID wraparound (i.e., the autovacuum query name in the <structname>pg_stat_activity</structname> view ends with <literal>(to prevent wraparound)</literal>), the autovacuum is not automatically interrupted. 自動バキュームワーカーは通常は他のコマンドをブロックしません。 自動バキュームが保持するSHARE UPDATE EXCLUSIVEロックと衝突するロックを、プロセスが獲得しようとした場合には、ロックの獲得により自動バキュームが中断されます。 衝突するロックモードに関しては表 13.2を参照してください。 しかしながら、自動バキュームがトランザクションIDの周回を防ぐために動作している(すなわち、pg_stat_activityビューの自動バキューム問い合わせ名が(to prevent wraparound)で終わっている)場合には、自動バキュームは自動的には中断されません。