> I previously then asked how the actual bits of the bundles are cleaned
> (or are they), because the database size on disk keeps growing
> constantly. I was then informed that vacuuming should release the actual
> disk space.

When you update or delete a row in postgres, this row is marked as invalid and in
case of update a new row is appended.

Now vacuum with the standard options is going through the table and finding all
those rows that are marked as invalid and is setting them to "fresh" so that subsequent
inserts can re-use those rows so that the table size is indeed not growing indefinitely.

So what you were seeing here is that a pure vacuum (which runs automatically
in postgres when certain assumptions are met and which the JBossON server is
running in default settings every hour) is just going through the database and is 
marking those rows as fresh. It does not try to compact any database files.

There is an option 'full' to vacuum that tries indeed to reclaim the disk space
of the unused rows. This option is not enabled by default, because 
- it acquires an exclusive lock on the table and thus prevents access by the JBossON server
- in cases where there will be new rows added immediately, shrinking the file (that backs a table) 
 and extending it directly afterwards is more expensive than just re-using the file.

So what you can do it to manually trigger a "vacuum full" on the database when there is no load
(or only on the bundle tables, when you know noone is accessing them).


-----

The new operation vacuum_full  would be by default for postgres and a no-op for other databases - until we find out how we can help them how to reclaim the space.