定常的なバキューム作業

PostgreSQL 8.4.1文書
前のページ | 巻戻し | 第 23章定常的なデータベース保守作業 | 早送り | 次のページ

# 23.1. 定常的なバキューム作業

PostgreSQLデータベースはvacuum作業として知られている定期的な保守を必要とします。多くのインストレーションでは、項23.1.5で説明されているautovacuumデーモンでのvacuum作業を行わせることで充分です。それぞれの状況に合った最善の結果を得るため、そこに書かれているautovacuum作業パラメータの調整が必要かもしれません。データベース管理者によっては、cronもしくはタスクスケジューラスクリプトに従って典型的に実行される、手作業管理の`VACUUM`コマンドによりデーモンの活動を補足したり、交換したりすることを意図するかもしれません。手作業管理のvacuum作業を適切に設定するためには、以下のいくつかの小区分で説明している問題点を理解することが必須です。autovacuum作業に信頼をおいている管理者にとっても、この資料に目を通すことはそれらの理解とautovacuum作業の調整に役に立つことでしょう。

## 23.1.1. バキューム作業の基本

PostgreSQLのVACUUMコマンドは以下の理由により定期的にそれぞれのテーブルを処理しなければなりません。

1. 更新、あるいは削除された行によって占められたディスク領域の復旧または再利用。

2. PostgreSQL問い合わせプランナによって使用されるデータ統計情報の更新。

3. トランザクションIDの周回による非常に古いデータの損失を防止。

次の小区分で説明されているように、変化する頻度と領域に対する`VACUUM`操作実行について、これら理由の１つ１つを指示しています。

標準`VACUUM`と`VACUUM FULL`の２つの`VACUUM`の種類があります。`VACUUM FULL`はディスク容量をあけるための再構成が可能ですが、実行にとても時間がかかります。また、`VACUUM`の標準形式では、実運用データベースに対する操作と並行して実行させることができます。（`SELECT`、`INSERT`、`UPDATE`、`DELETE`などのコマンドは通常通りに動作し続けます。しかし、バキューム処理中は`ALTER TABLE ADD COLUMN`などのコマンドを使用してテーブル定義を変更することはできません。）`VACUUM FULL`はそれが作用する全てのテーブルに対し排他ロックを必要とするので、それらテーブルのその他の用途と並行して行うことはできません。その他の`VACUUM FULL`の不都合としては、テーブルサイズを減少させる一方、それに比例してインデックスサイズを縮小させるわけではないことです。実際、インデックスが増大する場合があります。一般的に、管理者は標準`VACUUM`の使用に努め、`VACUUM FULL`の使用を避けるべきです。`VACUUM`には、かなりの量のI/Oトラフィックを発生させます。このため、他の実行中のセッションの性能を劣化させる場合があります。バックグラウンドで実行されるバキューム処理による性能への影響を軽減させることを調整できるような設定パラメータがあります。項18.4.3を参照してください。

## 23.1.2. ディスク容量の復旧

PostgreSQLは、行の`UPDATE`もしくは`DELETE`が古い行を即座に削除しません。 この方法は、多版同時性制御（第13章を参照してください）の恩恵を受けるために必要なものです。 あるバージョンの行は他のトランザクションから参照される可能性がある場合は削除されてはなりません。 しかし、結局は、更新される前の行や削除された行を参照するトランザクションはなくなります。 必要なディスク容量が無限大にならないように、これらが占める領域は、新しい行で再利用できるように回収されなければなりません。 これは`VACUUM`を実行することで行われます。

`VACUUM`の標準形式はテーブルとインデックス内の終わっている行バージョンを削除し、将来の再利用を可能にするための場所に印を付けます。しかし、テーブルの最後の１つ以上複数ページが完全にすいていて、また排他テーブルロックが容易に獲得できる特殊な場合を除き、その場所をオペレーティングシステムに返還しません。それとは反対に、`VACUUM FULL`は積極的に行バージョンを以前のページに移動させることでテーブルを圧縮します。このようにしてテーブルの終わりのページを完全に空にさせ、直ぐにそれらをオペレーティングシステムに返還します。しかし、多くの行を移動しなければなならい場合、長時間かかります。また、行の移動には過渡的にそれに対する重複したインデックス項目を作成するので（その新規場所を示す項目は旧項目が削除される前に作成されなければなりません）、このようにして大量の行を移動すると深刻なインデックス膨張の原因になります。

定常的なバキューム作業の通例の目安は`VACUUM FULL`の必要性を避けるに充分な頻度で標準`VACUUM`を行うことです。autovacuumデーモンはこのようにして作動を試みます。そして実際`VACUUM FULL`を行いません。この手法において、その発想はテーブルを最小サイズに保つのではなく、ディスク空間使用の安定状態を保持することです。それぞれのテーブルは、その最小サイズにバキューム作業とバキューム作業の間で使用されることになる容量を加えたのに等しい空間を占有します。`VACUUM FULL`はテーブルをその最小サイズまで縮小し、ディスク空間をオペレーティングシステムに返還するとは言っても、将来そのテーブルが再び肥大するのであれば、これは核心を突いていません。従って、程よい頻度の標準`VACUUM`を実行するほうが、不定期の`VACUUM FULL`を実行するより大量の更新テーブルを保守するにはより良い取り組みとなります。

例えば負荷が少ない夜間に全ての作業を行うように、管理者の何人かは自身で計画したバキューム作業の方を選びます。固定したスケジュールに従ってバキューム作業を行うことについての困難とは、もし更新作業でテーブルが予期せぬ急増に遭遇した場合、開き空間を再獲得するために`VACUUM FULL`が本当に必要となるところまで肥大化します。autovacuumデーモンの使用により、この問題を緩和します。なぜなら、デーモンは更新作業に反応して動的にバキューム作業を計画化するからです。極めて予測可能な作業量を保有している以外、デーモンを完全に無効化するのは賢いことではありません。１つの可能性のある妥協案は、いつになく激しい更新作業にのみ反応するよう、デーモンのパラメータを設定することです。そうすると、負荷が標準的な場合、大量の作業を計画化された`VACUUM`が行うことを期待する一方、物事が手が届かなくならないように保つことができます。

自動バキュームを使用しない場合の典型的な方式は、データベース全体の`VACUUM`を1日1回使用頻度が低い時間帯にスケジュールすることです。 必要に応じて、更新頻度の激しいテーブルのバキューム処理をより頻繁に行うよう追加してください （非常に高い頻度でデータの更新を行うインストレーションの中では、分間隔位という頻度で高負荷なテーブルの`VACUUM`を行うこともあります）。 1つのクラスタで複数のデータベースがある場合、それぞれをバキュームすることを忘れないでください。 vacuumdbプログラムが役に立つかもしれません。

> ティップ: 大規模な更新や削除作業の結果としてテーブルが大量の意味のない行バージョンを含む場合、どのような形式の`VACUUM`も完全に満足のゆくものではありません。もしそのようなテーブルを所有し、それが占有する余分なディスク空間の再獲得が必要であれば、最善策はCLUSTERを使用するか、table-rewritingの変異体の１つであるALTER TABLEを使用します。これらのコマンドはテーブルの全体の新規コピーを書き換え、それに対する新規インデックスを作成します。`VACUUM FULL`のように、それらは排他ロックを必要とします。新しいものが完成するまで、テーブルの旧コピーとインデックスは開放されないので、追加ディスク空間も一時的に使用することに注意してください。ディスクがほぼ満杯の最悪事態の場合、`VACUUM FULL`がたった一つの有効な選択肢です。

> ティップ: テーブルの内容が定期的に完全に削除される場合、`DELETE`の後に`VACUUM`を使用するよりも、TRUNCATEを使用する方が良いでしょう。 `TRUNCATE`はテーブルの全ての内容を即座に削除します。 また、その後に不要となったディスク容量を回収するために`VACUUM`や`VACUUM FULL`を行う必要がありません。 不利な点は厳格なMVCC動作が違反となることです。

## 23.1.3. プランナ用の統計情報の更新

PostgreSQL問い合わせプランナは、優れた問い合わせ計画を作成するのに、テーブルの内容に関する統計情報に依存しています。 この統計情報はANALYZEによって収集されます。 このコマンドはそのものを呼び出す以外にも、`VACUUM`のオプション処理としても呼び出すことができます。 合理的な精度の統計情報を持つことは重要です。 さもないと非効率的な計画を選択してしまい、データベース性能を悪化させてしまいます。

自動バキュームデーモンが有効になっている場合は、テーブルの内容が正確に変更されたときはいつでも自動的に`ANALYZE`コマンドを発行します。しかし、特にテーブルの更新作業が"興味のある"列の統計情報に影響を与えないことが判っている時、手作業により計画された`ANALYZE`操作を当てにする方が好ましいと管理者は思うかもしれません。デーモンは、挿入または更新された行数の関数として`ANALYZE`をきっちりと計画します。しかし、意味のある統計情報の変更につながるかどうかは判りません。

領域復旧のためのバキューム処理と同様、頻繁な統計情報の更新は、滅多に更新されないテーブルよりも更新の激しいテーブルにとってより有益です。 しかし、頻繁に更新されるテーブルであっても、データの統計的な分布が大きく変更されなければ、統計情報を更新する必要はありません。 単純な鉄則は、テーブル内の列の最小値、最大値にどのくらいの変化があったかを考えることです。 例えば、行の更新時刻を保持する`timestamp`列の場合、最大値は行が追加、更新されるにつれて、単純に増加します。 こういった列は、おそらく、例えば、あるWebサイト上のアクセスされたページのURLを保持する列よりも頻繁に統計情報を更新する必要があるでしょう。 このURL列の更新頻度も高いものかもしれませんが、その値の統計的な分布の変更は相対的に見ておそらく低いものです。

特定のテーブルに対して`ANALYZE`を実行することができます。 また、テーブルの特定の列のみに対してさえも実行することができます。 ですので、アプリケーションの要求に応じて、他よりも頻繁に一部の統計情報を更新できるような柔軟性があります。 しかし、実際には、操作が高速であるため、単にデータベース全体を解析することが最善です。 `ANALYZE`は、すべての行を読むのではなく、テーブルからランダムに行を抽出して統計処理に使用します。

> ティップ: 列単位での`ANALYZE`実行頻度の調整は非常に実用的とは言えるものではありませんが、`ANALYZE`で集計される統計情報の詳細レベルの調整を列単位で行うことは価値がある場合があります。 `WHERE`句でよく使用され、データ分布の規則性がほとんどない列は、他の列よりもより細かいデータの度数分布が必要になるでしょう。 `ALTER TABLE SET STATISTICS`を参照するか、default_statistics_target設定パラメータでデータベース全体のデフォルトを変更してください。

## 23.1.4. トランザクションIDの周回エラーの防止

PostgreSQLのMVCCトランザクションのセマンティックは、トランザクションID（XID）番号の比較が可能であることに依存しています。 現在のトランザクションのXIDよりも新しい挿入時のXIDを持ったバージョンの行は、"未来のもの"であり、現在のトランザクションから可視であってはなりません。 しかし、トランザクションIDのサイズには制限（執筆時点では32ビット）があり、長時間（40億トランザクション）稼働しているクラスタはトランザクションの周回を経験します。 XIDのカウンタが一周して0に戻り、そして、突然に、過去になされたトランザクションが将来のものと見えるように、つまり、その出力が不可視になります。 端的に言うと、破滅的なデータの損失です （実際はデータは保持されていますが、それを入手することができなければ、慰めにならないでしょう）。 これを防ぐためには、すべてのデータベースにあるすべてのテーブルを少なくとも20億トランザクションごとにバキュームする必要があります。

定期的なバキューム処理によりこの問題が解決する理由は、PostgreSQLが特別なXID、`FrozenXID`を区別しているためです。 このXIDは常に全ての通常のXIDよりも古いものとみなされます。 通常のXID（2以上の値）はmodulo-231という数式を使用して比較されます。 これは、全ての通常のXIDでは、20億の"より古い"XIDと20億の"より新しい"XIDが存在することを意味します。 言い換えると、通常のXID空間は終わることなく循環されているということです。 そのため、ある特定のXIDであるバージョンの行を作成すると、そのバージョンの行は、以降の20億トランザクションからはどの通常のXIDについて比較しているのかには関係なく、 "過去のもの"と認識されます。 そのバージョンの行が20億トランザクション以上後にも存在していた場合、それは突然に未来のものとして認識されます。 このデータ損失を防ぐために、20億トランザクションより古いとみなされるより、少し前に古いバージョンの行のXIDを`FrozenXID`に再割り当てする必要があります。 この特殊なXIDに割り当てられた後は、周回問題に関係なく、全ての通常のトランザクションから"過去のもの"として認識され、また、そのバージョンの行はどれだけ古いものであろうと、削除されるまで好ましい状態となります。 この古いXIDの再割り当ては`VACUUM`で扱われます。

`vacuum_freeze_min_age`は、XID値が`FrozenXID`で置換される前に、旧XID値がどのくらい経過しているのかを制御します。より大きな`vacuum_freeze_min_age`によりトランザクション情報が長期間保持されます。 一方で、この値を小さくすることで、テーブルを次にバキュームする必要が起こるまで継続できるトランザクション数を増加させることができます。

`VACUUM`は通常もはや使用されない行バージョンを持っていないページを読み飛ばしますが、それらのページは旧XID値の行バージョンを未だ所有している可能性があります。全ての旧XIDが`FrozenXID`により置き換えられたかどうかの確証を得るためには、全てのテーブルの走査が必要です。 vacuum_freeze_table_ageは`VACUUM`がバキュームを行った際調整します。つまり、テーブル全体にわたる清掃は`vacuum_freeze_table_age`から`vacuum_freeze_min_age`を差し引いたトランザクションに対しテーブルが完全に走査されていない場合に強制されます。 0に設定することで`VACUUM`が可視性マップを効果的に無視し、常に全てのページを走査するようにさせます。

テーブルをバキュームすることなく処理できる最大の時間は、20億トランザクションから`VACUUM`が前回テーブル全体を走査した際に使用された`vacuum_freeze_min_age`を差し引いたものです。この時間よりも長期間バキュームを行わないと、データ損失が発生します。 これを確実に防止するために、自動バキュームデーモンがautovacuum_freeze_max_age設定パラメータで指定された時代より古いXIDを持つ可能性がある任意のテーブルに対して呼び出されます。 （これは自動バキュームが無効であっても起こります。）

これは、 あるテーブルがバキュームされていなかったとしても、自動バキュームがおよそ`autovacuum_freeze_max_age` - `vacuum_freeze_min_age`トランザクション毎に呼び出されることを意味します。 領域確保のために定常的にバキューム処理を行うテーブルでは、これは重要ではありません。 しかし、（挿入のみで更新や削除が行われないテーブルを含む）静的なテーブルでは、領域確保のためのバキューム処理を行う必要がなくなりますので、非常に長期間静的なテーブルでは、強制的な自動バキューム間の間隔を最大まで延ばすことができます。 記載するまでもありませんが、`autovacuum_freeze_max_age`を増やすことでも`vacuum_freeze_min_age`を減らすことでも、これを行うことができます。

`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`より多少低い値に設定されるべきです。これを余りにも近づいた値に設定すると、たとえ余白空間を確保するため最近テーブルがバキュームされたとしても対包括自動バキュームに帰着します。一方より低い値はより頻繁なテーブル全体の走査を引き起こします。

`autovacuum_freeze_max_age`（およびそれに付随する`autovacuum_freeze_max_age`）を増やす唯一欠点は、データベースクラスタのサブディレクトリ`pg_clog`がより大きな容量となることです。 `autovacuum_freeze_max_age`の範囲まですべてのトランザクションのコミット状況を格納しなければならないためです。 コミット状況は1トランザクション当たり2ビット使用しますので、もし`autovacuum_freeze_max_age`がその最大許容値である2億よりすこし少ない値に設定している場合、`pg_clog`はおよそ0.5ギガバイトまで膨らむものと考えられます。 これがデータベースサイズ全体に対してとるに足らないものであれば、`autovacuum_freeze_max_age`を最大許容値に設定することを勧めます。 さもなければ、`pg_clog`の容量として許容できる値に応じてそれらを設定してください。 （デフォルトは2000万トランザクションです。換算すると`pg_clog`はおよそ50メガバイトの容量となります。）

`vacuum_freeze_min_age` を減らすことにも1つ欠点があります。 これにより`VACUUM`が大して役に立たなくなるかもしれません。 テーブル行がすぐに変更される場合（新しいXIDを獲得することになります）、テーブル行のXIDを`FrozenXID`に変更することは時間の無駄です。 そのため、この設定は、行の変更が起こらなくなるまで凍結されない程度に大きくすべきです。 この設定を減らすことによる他の欠点として、行を挿入または変更したトランザクションに関する情報がすぐに失われることです。 この情報は、特に、データベース障害の後、何がうまくいかなかったのかを解析する場合、便利になることがあります。 この2つの理由により、この設定を減らすことは完全に静的なテーブルでない限りお勧めしません。

データベース内のもっとも古いXIDの年代を追跡するために、`VACUUM`はシステムテーブル`pg_class`と`pg_database`にXID統計情報を保持します。 特に、テーブル`pg_class`行の`relfrozenxid`列には、テーブルに対する最後のテーブル全体の`VACUUM`で使用された凍結切捨てXIDが含まれます。 この切り捨てXIDよりも古い、全ての通常のXIDはそのテーブルの`FrozenXID`によって置換されていることが保証されています。 同様に、データベースの`pg_database`行の`datfrozenxid`列は、データベース内で現れる通常のXIDの下限値です。 これは、そのデータベース内のテーブル当たりの`relfrozenxid`値の最小値です。 この情報を検査する簡便な方法は、以下の問い合わせを実行することです。

    SELECT relname, age(relfrozenxid) FROM pg_class WHERE relkind = 'r';
    SELECT datname, age(datfrozenxid) FROM pg_database;

`age`列は切り捨てXIDから現在のトランザクションXIDまでのトランザクション数を測ります。

`VACUUM`は通常最後のバキュームから変更されたページのみ走査しますが、`relfrozenxid`はテーブル全体が走査されたときのみ繰り上がります。テーブル全体は、`VACUUM FREEZE`コマンドが使用された時、もしくは使用されない行バージョンを削除するため全てのページをバキュームしなければならなくなった時、`relfrozenxid`が`vacuum_freeze_table_age`トランザクション年齢より大きい場合走査されます。`VACUUM`がテーブル全体を走査した直後、`age(relfrozenxid)`は、使用された`vacuum_freeze_min_age`設定より若干大きくなるはずです（`VACUUM`を起動してから始まったトランザクションの数分大きくなります）。もしテーブル全体走査`VACUUM`が`autovacuum_freeze_max_age`に達するまでにテーブルに対して発行されない場合、そのテーブルに対してautovacuumが早急に強制されます。

何らかの理由により自動バキュームがテーブルの古いXIDの整理に失敗した場合、システムはデータベースの最古のXIDが周回ポイントから1000万トランザクションに達した場合と似たような警告メッセージを発行し始めます。

    WARNING:  database "mydb" must be vacuumed within 177009986 transactions
    HINT:  To avoid a database shutdown, execute a database-wide VACUUM in "mydb".

（ヒントで示唆されたように手動`VACUUM`はこの問題を解決します。しかし、`VACUUM`はスーパユーザで実行されなければならず、さもないとシステムカタログの処理に失敗し、従ってデータベースの`datfrozenxid`を桁上げすることができません。） こうした警告も無視し続け、周回するまでのトランザクションが100万より少なくなると、システムは停止し、新しいトランザクションの実行を拒絶します。

    ERROR:  database is not accepting commands to avoid wraparound data loss in database "mydb"
    HINT:  Stop the postmaster and use a standalone backend to VACUUM in "mydb".

この100万トランザクションという安全マージンは、管理者が必要な`VACUUM`コマンドを手作業で実行することで、データを失うことなくリカバリすることができるようにするために存在します。 しかし、システムがこの安全のための停止モードになると、コマンドを実行しませんので、 実行するためには、サーバを停止し、シングルユーザモードのバックエンドを使用して`VACUUM`を行う他ありません。 停止モードはシングルユーザモードのバックエンドでは強制されません。 シングルユーザモードのバックエンドの使用に関する詳細はpostgresマニュアルページを参照してください。

## 23.1.5. 自動バキュームデーモン

PostgreSQLは省略可能では有りますが、強く推奨される自動バキュームという機能があります。 これは`VACUUM`と`ANALYZE`コマンドの実行を自動化することを目的としたものです。 有効にすると、自動バキュームは大量のタプルの挿入、更新、削除があったテーブルを検査します。 この検査は統計情報収集機能を使用します。 したがって、track_countsが`true`に設定されていないと、自動バキュームを使用することができません。 デフォルトの設定では、自動バキュームは有効で、関連するパラメータも適切に設定されています。

"自動バキュームデーモン"は実際複数のプロセスから構成されます。 自動バキュームランチャという永続的デーモンプロセスが存在し、自動バキュームワーカプロセスがすべてのデータベースを処理します。 ランチャは、あるワーカの起動が各データベースに対しautovacuum_naptime秒ごとに開始するよう試みることにより、時間に対して作業を分散化します。 ワーカはデータベースごとに、同時に最大autovacuum_max_workersプロセスが実行するように、起動されます。 autovacuum_max_workersより多くのデータベースを処理させる場合、次のデータベースは最初のワーカが終了するとすぐに処理されます。 それぞれのワーカプロセスはデータベース内の各テーブルを検査し、必要に応じて`VACUUM`または`ANALYZE`コマンドを発行します。

autovacuum_max_workersの設定は、任意時点におけるワーカの実行可能個数を制限します。 もし、短期間にかなり多くのテーブルがすべてバキューム対象として適切な状態になったとすると、すべての自動バキュームワーカはこうしたテーブルに対するバキューム処理に長い期間占領される可能性があります。 これにより、ワーカが利用できるようになるまで、他のテーブルやデータベースに対するバキュームが行われなくなります。 また、単一データベースに対するワーカ数には制限はなく、ワーカはすでに他のワーカによって実行された作業を繰り返さないように試みます。 ワーカの実行数はmax_connections制限にもsuperuser_reserved_connections制限にも計上されないことに注意してください。

テーブルの`relfrozenxid`値がautovacuum_freeze_max_ageトランザクション年齢よりも古い場合、そのテーブルは常にバキュームされます（これはfreeze max ageがストレージパラメータにより変更されたテーブルに対しても適用されます。以下を参照）。 さもなければ、直前の`VACUUM`の後に不要となったタプル数が"バキューム閾値"を超えると、テーブルはバキュームされます。 このバキューム閾値は以下のように定義されます。

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

ここで、バキューム基礎閾値はautovacuum_vacuum_threshold、バキューム規模係数はautovacuum_vacuum_scale_factor、タプル数は`pg_class`.`reltuples`です。 不要となったタプル数は、統計情報コレクタから取り出されます。 これは、各`UPDATE`、`DELETE`操作で更新される、ほぼ正確な数です。（負荷が高いと一部の情報が失われる可能性があることから、これはほぼ正確な数でしかありません。）テーブルの`relfrozenxid`値が`vacuum_freeze_table_age`トランザクション年齢より大きい場合、テーブル全体は古いタプルを凍結するため走査され、`relfrozenxid`を繰り上げます。そうでなければ最後のバキュームの後に変更されたページのみ走査されます。

以下で定義される閾値が、直前の`ANALYZE`の後に挿入、更新されたタプル数と比較されます。

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

デフォルトの閾値と規模係数は、`postgresql.conf`から取られますが、テーブル毎に上書きすることができます。より詳細な情報は格納パラメータを参照してください。 ストレージパラメータで設定が変更されるとその値が使用されます。そうでなければ、全体設定が使われます。全体設定についての詳細な情報は、項18.9を参照してください。

基礎閾値と規模係数の他に、ストレージパラメータでを各テーブルに対して設定することができる更に６つのautovacuumパラメータがあります。 最初のパラメータ、`pg_autovacuum`は`false`に設定することでautovacuumデーモンにこのテーブル全体を対象から外すようにします。 この場合autovacuumは、トランザクションIDの周回を防ぐためにバキュームする必要がある時のみ、このテーブルを対象とします。 別の２つのパラメータ、`autovacuum_vacuum_cost_delay`と `autovacuum_vacuum_cost_limit`はコストに基づくVacuum遅延機能に対し、テーブル特定の値を設定するために使用されます。 `autovacuum_freeze_min_age`、 `autovacuum_freeze_max_age`および `autovacuum_freeze_table_age` は、それぞれvacuum_freeze_min_age、 autovacuum_freeze_max_ageおよび vacuum_freeze_table_ageに対する値を設定するために使用されます。

複数のワーカプロセスの実行中、コスト制限は実行中のワーカ全体に"振り分け"られます。 このため、ワーカの実稼働数に関らず、システムに与える総影響は変わりありません。

前のページ | ホーム | 次のページ
定常的なデータベース保守作業 | 上に戻る | 定常的なインデックスの再作成