4

データベースのメンテナンススクリプトを作成しました。毎日のダウンタイム中にバキューム/インデックスの再作成が最も必要なテーブルでそのスクリプトを実行したいと思います。postgres内でそれを判断する方法はありますか？

私はこのように注意が必要なテーブルを分類します：

  • 掃除機が必要なテーブル
  • インデックスの再作成が必要なテーブル（これによりパフォーマンスに大きな違いが生じることがわかります）

ここで大まかに有望なものが見えます

4

3 に答える 3

4

自動掃除機を再発明しようとしているようです。それを有効にして、それを仕事に任せることができない理由は何ですか？

必要な実際の情報については、pg_stat_all_tablesおよびpg_stat_all_indexesを参照してください。

その中のデータを使用する方法の良い例については、自動バキュームのソースを見てください。ビューを直接クエリすることはありませんが、その情報を使用します。

于 2009-06-25T09:29:26.463 に答える
0

CRUD アクションの後に実行される同じトリガー関数をすべてのテーブルに追加するのはどうでしょうか。

この関数はテーブル名を受け取り、テーブルのステータスをチェックしてから、そのテーブルでバキュームまたは再インデックスを実行します。

「単純な」pl/sqlトリガーである必要がありますが、それらは決して単純ではありません...

また、DB マシンが十分に強力で、ダウンタイムが十分に長い場合は、毎晩スクリプトを実行してすべてのインデックスを再作成し、すべてをバキュームします...そのようにして、テスト時間 (夜) に基準が満たされていない場合でも、はそれに近かった（基準より少ない数のレコード）、基準に達した翌日に問題が発生することはありません...

于 2010-07-19T22:01:17.653 に答える
0

自動バキュームを検討する必要があると思います。

しかし、私があなたのニーズを正しく理解していれば、それが私がすることです:

  • すべてのテーブル (いくつのテーブルがありますか?) について基準を定義します。

たとえば、talbe 'foo' は、X 個の新しいレコードごとにインデックスを再作成し、X 個の更新、削除、または挿入ごとにバキュームする必要があります。

  • それを行うには、独自のアプリケーションを作成します。

毎日テーブルのステータスをチェックし、それをログに保存して (時間の経過に伴う行の違いを比較するため)、基準に一致するテーブルを再インデックス化/バキュームします。

少しハッキングに聞こえますが、これは良い方法だと思いますcustom-autovacuum-with-custom-'triggers'-criteria

于 2010-01-22T10:44:12.670 に答える