Re: auto vacuum doens't appear to be working

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