Re: Reclaiming space

But how would the newer version prevent bloat and eliminate making the
database unavailable while the *maintenance* goes on?

The database is more than five years old, and we did not delete records
until recently and when we do delete them, naturally the records are in
front of the table and the lazy vacuum cannot reclaim the space. The
full vacuum does since it consolidates all the unused space at the
expense of locking the table. In our case our clients rely on our
availability. The newer version(s) of postgres still has this problem
of not reclaiming space unless we lock the table so we do not see any
compelling reason to upgrade. But seeing 9.0 includes an improved
vacuum makes it worth looking into.

Perhaps there is a more direct approach to remove the bloat, like with a
sql statement or some third party utility? We did use the pg_autovacuum
and unless I am mistaken, that should be enough maintenance. We store
millions of records (1 record contains a blob of up to 5mb) per month
and if it weren't for the vacuums then it would have been filled up long
ago. But we still wonder why after we deleted a years worth of data,
the db still grew bigger.

On 9/22/2010 12:16 AM, Joshua D. Drake wrote:
> On Tue, 2010-09-21 at 20:39 +0800, Christopher Gorge A. Marges wrote:
>> We are using 7.4.13 and run the pg_autovacuum. Over the years, the
>> database has grown so our maintenance plan was to "move" everything
>> except for the last year. Since the server is kept up always using a
>> full vacuum is out of the question. However the space is running out
>> and we tried installing contrib/dbsize to see which tables were using
>> up space. The report of database_size is correct, we are using up to
>> 120G of space, but adding up the reported sizes from relation_size
>> does not add up. So where does the unused space go?
> Bloat. All databases have bloat. If you aren't maintaining "enough" you
> are going to continue to use up more and more hd space.
>
> Also, 7.4 is about to be deprecated. I *STRONGLY* Suggest you migrate to
> at least 8.2. Preferably 8.4 but that will likely take more work do to
> removal of implicit casts in 8.3.
>
>> The steps we do to move the data is as follows:
>> 1) dump the data (per table)
>> 2) restore the data to another server
>> 3) delete the dumped records from the production server
>> 4) vacuum analyze
> You could consider installing a version of Slony that still supports 7.4
> and then "replicate" the data to the new server.
>
>> Is there anyway to reclaim the space (the space used up by the tables
>> themselves are less than 20G).
> Not without an outage on the relation.
>
> Joshua D. Drake
>
>
>
>
> No virus found in this incoming message.
> Checked by AVG - www.avg.com
> Version: 9.0.851 / Virus Database: 271.1.1/3148 - Release Date: 09/21/10 01:04:00
>

--
------------------------------------------------------------------------
*Christopher Gorge A. Marges*
/Software Services/
/Apollo Technologies, Inc./