2011-08-01 26 views
8

テーブルの統計が古く、それが要求されますされているときは常にpgAdminで、で:Postgresテーブルの統計情報が最新のものであるかどうかを知るにはどうすればよいですか?

をVACUUMを実行

を推奨テーブルにschema.tableの推定行数は、実際の行数から大幅に を逸脱します。このテーブルでVACUUM ANALYZE を実行する必要があります。

私は、autovacuum = offのpgAdmin 3とPostgres 8.4.4を使ってテストしました。変更された表をクリックすると、すぐにプロンプ​​トが表示されます。

WebベースのシステムをJavaで作っているとしましょう。pgAdminのようなプロンプトを表示できるように、テーブルが古いかどうかを検出するにはどうしたらいいですか?そのため、私のアプリケーションの性質の

、ここで私は従わなければならないいくつかのルールは以下のとおりです。

  1. は私がでpg_statsとpg_statisticの特定のテーブルの統計情報が最新であるかどうかを知りたいです。

  2. 私はautovacuumフラグをpostgresql.confに設定できません。 (つまり、自動バキュームフラグはオンまたはオフにすることができます。私はそれを制御できません。自動バキュームフラグがオンであるかオフであるかによって統計情報が最新であるかどうかを知る必要があります)。

  3. Iそれを最新のものにするために毎回真空分析/分析を実行することはできません。

  4. ユーザーがテーブルを選択したとき、pg_statsおよびpg_statisticに反映されていないこのテーブルの更新(drop、insert、およびupdateなど)があるときに、テーブルが古くなっていることを示すプロンプトを表示する必要があります。

pg_catalog.pg_stat_all_tablesのタイムスタンプを分析することは現実的ではないようです。もちろん、以前にテーブルが解析されていない場合、last_analyzeにタイムスタンプがあるかどうかを調べて、テーブルが最新であるかどうかを調べることができます。ただし、このメソッドを使用すると、タイムスタンプがすでにある場合にテーブルが最新であるかどうかを検出できません。言い換えれば、テーブルに何行追加しても、pg_stat_all_tablesのlast_analyzeタイムスタンプは常に最初の解析用です(autovacuumフラグがオフであると仮定します)。したがって、初めて「Running VACUUM recommended」プロンプトが表示されるだけです。

last_analyzeタイムスタンプと現在のタイムスタンプを比較することによっても実現できません。数日間、テーブルの更新がない可能性があります。そして、1時間で更新のトンがあるかもしれません。

この場合、テーブルの統計情報が最新のものであるかどうかを常に知るにはどうすればよいですか?

答えて

2

あなたのアプリケーションでは、休暇を心配する必要はありません。代わりに、autovacプロセスをサーバー(postgresql.conf)に設定する必要があります。サーバーは、独自の内部統計に基づいてVACCUMANALYZEの処理を実行します。実行する頻度と、それを処理するためのしきい値変数を構成できます。

+0

こんにちはアーロンは、答えてくれてありがとう。しかし、アプリケーションの性質上、postgresql.confにautovacuumフラグを設定することはできません。 autovacuumフラグはオンまたはオフにすることができます。私はそれを支配していない。 – Beibei

+1

DBAと連絡を取り合えますか?ホストされたアプリケーションであっても、オートバックスデーモンが動作している必要があります。特にPostgresは非常に細分化されています。 – atrain

12

システムカタログを確認してください。そこに有用な情報の

test=# SELECT schemaname, relname, last_analyze FROM pg_stat_all_tables WHERE relname = 'city'; 
schemaname | relname |   last_analyze   
------------+---------+------------------------------- 
pagila  | city | 2011-07-26 19:30:59.357898-07 
world  | city | 2011-07-26 19:30:53.119366-07 
(2 rows) 

すべての種類:

test=# \d pg_stat_all_tables   View "pg_catalog.pg_stat_all_tables" 
     Column  |   Type   | Modifiers 
-------------------+--------------------------+----------- 
relid    | oid      | 
schemaname  | name      | 
relname   | name      | 
seq_scan   | bigint     | 
seq_tup_read  | bigint     | 
idx_scan   | bigint     | 
idx_tup_fetch  | bigint     | 
n_tup_ins   | bigint     | 
n_tup_upd   | bigint     | 
n_tup_del   | bigint     | 
n_tup_hot_upd  | bigint     | 
n_live_tup  | bigint     | 
n_dead_tup  | bigint     | 
last_vacuum  | timestamp with time zone | 
last_autovacuum | timestamp with time zone | 
last_analyze  | timestamp with time zone | 
last_autoanalyze | timestamp with time zone | 
vacuum_count  | bigint     | 
autovacuum_count | bigint     | 
analyze_count  | bigint     | 
autoanalyze_count | bigint     | 
+0

答えてくれてありがとう、ショーン。私はpg_stat_all_tablesを試しました。私は、分析の前に初めて時代遅れのテーブルを伝えることができました。しかし、同じテーブルに変更が加えられたときをどのようにして伝えるかはわかりません。更新された質問をご覧ください。 – Beibei

+1

私はテーブルに統計情報が追加されているかどうかを調べる方法を見つけました。このトリックは、ビュー "pg_catalog.pg_stat_all_tables"と** reltuples **をテーブル "pg_catalog.pg_class"で比較することです。** n_tup_ins **(** ** n_live_tup **) このメソッドは、行数が同じになっても更新を検出できませんが、私の問題を満たします。 – Beibei

+0

バックエンドのすべてのクエリをログに記録し、pgAdminに接続するとどうなるかを確認してください。自動バキュームを有効にすることに関する上記のコメントは、別のポスターからのものです。例外的にエキゾチックなニーズがあり、自動バキュームを使用して回避しようとしていることを正確に把握していない限り、自動バキュームを実行する必要があります(チャンスはありませんが、自動バキュームを避けるべきではありません)。これがあなたの決定でない場合は、このケースを意思決定者である人にしてください。 – Sean

関連する問題