Thanks for the help. The applied solution follows. We will be taking a
number of maintenance steps to manage these very high update tables
which I will summarize later as I suspect we are not the only ones with
this challenge.
http://www.postgresql.org/docs/current/interactive/routine-vacuuming.html#VACUUM-FOR-WRAPAROUND
http://www.postgresql.org/docs/current/interactive/catalog-pg-autovacuum.html
data_store=# SELECT relname, oid, age(relfrozenxid) FROM pg_class WHERE
relkind = 'r';
...
hour_summary | 16392 | 252934596
percentile_metadata | 20580 | 264210966
(51 rows)
data_store=# insert into pg_autovacuum values
(16392,false,350000000,2,350000000,1,200,200,350000000,500000000);
INSERT 0 1
data_store=# insert into pg_autovacuum values
(20580,false,350000000,2,350000000,1,200,200,350000000,500000000);
INSERT 0 1
data_store=#
hubert depesz lubaczewski wrote:
> On Tue, Aug 26, 2008 at 10:45:31AM -0600, Jerry Champlin wrote:
>
>> This makes sense. What queries can I run to see how close to the limit
>> we are? We need to determine if we should stop the process which
>> updates and inserts into this table until after the critical time this
>> afternoon when we can perform the required maintenance on this table.
>>
>
> select datname, age(datfrozenxid) from pg_database;
>
> Best regards,
>
> depesz
>
>