Hi there
1. PG 8.1.9 is ancient ... you should upgrade.
2. The database gross size on disk is not affected by VACUUM ANALYZE ... all this does is return space used by deleted row-versions to PG for re-use. The only way to reduce it and thus return disk space to the OS is to do a VACUUM FULL, or to delete the entire table.
3. If you can suspend writes for a while, you can pull off an "online" VACCUM FULL, or copy and delete the table in order to repack it. Check out the CLUSTER command.
4. If you're trying to figure out the net size of the table, i.e. how much free space is inside the table files for reuse by PG, then you need the pg_stat_tuple function ... this is built in to PG 8.4, and a plug-in activated by a script for PG 8.3, don't know if it exists in 8.1 or not. Like SELECT COUNT(*) this requires a full table scan.
Cheers
Dave
sent from my Android phone
On Jun 20, 2010 6:18 AM, "venu madhav" <venutaurus539@xxxxxxxxx> wrote:
Hi All,
I am using Postgres 8.1.9 for my application. My application also has a clean up module which cleans up specified percentage of total database size at regular intervals. Now the problem is I use pg_database_size to obtain the size of the database. After deleting the records, we run Vacuum Analyze to reorder the indexes. The problem here is even though some records are cleared, it still shows the original DB Size. Is there any way to find out the actual DB Size or it would be more useful, if I can get the size of each table.
I can't run Vacuum Full because the application should be run 24*7 without downtime.
Can someone please help me in solving this.
Please let me know if you need any clarifications.
Thank you,
Venu.
