Re: auto vacuum doens't appear to be working

Also, remember that a regular vacuum won't actually free any disk
space*, it only marks it as re-useable in the table.

* OK, technically it will reclaim space from the very end of the table
* in certain circumstances, but in reality it's pretty rare for that to
* happen.

On Fri, Jun 30, 2006 at 11:09:14AM -0400, Tom Lane wrote:
> 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
>
> ---------------------------(end of broadcast)---------------------------
> TIP 3: Have you checked our extensive FAQ?
>
> http://www.postgresql.org/docs/faq
>

--
Jim C. Nasby, Sr. Engineering Consultant jnasby(at)pervasive(dot)com
Pervasive Software http://pervasive.com work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461