Warren Little <[EMAIL PROTECTED]> 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
