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
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 |