Re: Unexpectedly high disk space usage

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Lists <lists(at)benjamindsmith(dot)com>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: Unexpectedly high disk space usage
Date: 2012-11-07 20:42:59
Message-ID: 24041.1352320979@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Lists <lists(at)benjamindsmith(dot)com> writes:
> pg_catalog.pg_attribute | 36727480320

Ouch.

> Our current process is that every night in the middle of the night, a
> script connects to each database on each server and runs a query to get
> all tables in each database and, for each, run
> "VACUUM ANALYZE $table"
> for each table in the database.
> (note: there is a database for the "postgres" user on each DB server)
> The script is a remnant from PG 8.x days, so am I missing something
> fundamental about 9.x? I will note that autovacuum is off ...

So you've turned off autovacuum, and are carefully not vacuuming the
system catalogs. That's your problem all right. Is there a
particularly good reason why this script isn't a one-liner "VACUUM"?
Are you sure that once-a-day vacuuming is sufficient, even if it was
covering the system catalogs? If you've managed to bloat pg_attribute
to 36GB, I suspect you've got enough churn (perhaps from temp tables)
that you really need the catalogs vacuumed more often.

My advice is dump, reload, and *don't* turn off autovacuum.

> ... because it
> occasionally causes transactions and queries to hang when an update
> causes a vacuum mid-day, effectively taking us offline randomly.

I suspect this claim is based on ancient and no longer very relevant
experience.

regards, tom lane

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Bruce Momjian 2012-11-07 20:45:03 Re: Does PostgreSQL have complete functional test cases?
Previous Message Raymond O'Donnell 2012-11-07 20:33:54 Re: How to verify pg_dump files