Re: auto vacuum doens't appear to be working

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Warren Little <warren(dot)little(at)meridiascapital(dot)com>
Cc: pgsql-admin(at)postgresql(dot)org
Subject: Re: auto vacuum doens't appear to be working
Date: 2006-06-30 15:09:14
Message-ID: 24014.1151680154@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-admin

Warren Little <warren(dot)little(at)meridiascapital(dot)com> writes:
> when I run
> SELECT sum( relpages*8/1024 ) as MB FROM pg_class where relname != ''
> I get a value of 104995 which I interpret to mean I have 104GB of stored data
> in the database and this value has remained relatively static (+/- 1GB) over
> the past couple of weeks.
> We I to a df -h on the filesystem holding the database cluster I get a usage
> of 140GB. Again I interpret this to mean I have nearly 35GB of "uncleaned"
> data.

That conclusion is entirely incorrect --- relpages should be the whole
space usage for each table, assuming it's up-to-date (it might not be).
However a query done as above would account only for the current
database; perhaps the other space is in other databases? If you've had
database crashes in the past, there could be problems with unreferenced
files. Or the bloat could be in pg_xlog or one of the other overhead
directories, or not Postgres' fault at all considering that you're
examining the whole filesystem. A single "df" number won't help you pin
it down, you need to do more careful analysis. I'd start with a
directory-by-directory "du" listing, and check individual files if
necessary (contrib/oid2name or contrib/pgstattuple might help). For
background see
http://www.postgresql.org/docs/8.1/static/storage.html
(adjust for your PG version)

regards, tom lane

In response to

Responses

Browse pgsql-admin by date

  From Date Subject
Next Message Michael B. Babakov 2006-06-30 17:21:38 ERROR: invalid overflow block number 13947
Previous Message Alex Soto 2006-06-30 14:41:57 Constraint Null Value