Re: Get a list of ALL tables

Sorry, I meant to send this to the list:

We have a handful of tables that are quite large and take several hours to
vacuum. We're managing these large tables by using cron via a schedule that
accounts for system load. I want to pull the list of all tables and exclude
these large tables from the list, then run the vacuum on the remaining tables
once a week to avoid transaction ID wraparound failures.

/Kevin

> Kevin Kempter <kevin(at)kevinkempterllc(dot)com> writes:
> > I'm working with a client with several highly active 8.1.4 servers. I
> > want to run a weekly cron that will vacuum ALL db tables except those
> > with entries in pg_autovacuum (where we've setup manual/cron vacuums) in
> > order to eliminate transaction ID wraparound failure warnings (which
> > comes up fairly often).
> >
> > My question is:
> > will a select from pg_tables for each database in the cluster provide me
> > with a full table listing for the purposes of ensuring that all tables in
> > the db have been vacuumed or are there others I'll need to account for as
> > well ?
>
> Why are you insisting on inventing your own wheel for this, when
> "vacuum" without a parameter does that just fine?
>
>                       regards, tom lane

On Monday 19 November 2007 16:29:15 you wrote:
> Kevin Kempter <kevin(at)kevinkempterllc(dot)com> writes:
> > I'm working with a client with several highly active 8.1.4 servers. I
> > want to run a weekly cron that will vacuum ALL db tables except those
> > with entries in pg_autovacuum (where we've setup manual/cron vacuums) in
> > order to eliminate transaction ID wraparound failure warnings (which
> > comes up fairly often).
> >
> > My question is:
> > will a select from pg_tables for each database in the cluster provide me
> > with a full table listing for the purposes of ensuring that all tables in
> > the db have been vacuumed or are there others I'll need to account for as
> > well ?
>
> Why are you insisting on inventing your own wheel for this, when
> "vacuum" without a parameter does that just fine?
>
> regards, tom lane