Re: after vacuum, db is still "growing" :(

From: Rafael Martinez Guerrero <r(dot)m(dot)guerrero(at)usit(dot)uio(dot)no>
To: gabor <gabor(at)nekomancer(dot)net>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: after vacuum, db is still "growing" :(
Date: 2005-12-09 09:00:45
Message-ID: 1134118844.19512.68.camel@bbking.uio.no
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Fri, 2005-12-09 at 08:45, gabor wrote:
[...........]
>
> are there any cases, where a normal vacuum is unable to reclaim some
> space

Hello

We have det same problem in some databases running 7.4.8. Having
max_fsm_pages and max_fsm_relations properly configurated does not help.

It looks like this happens in tables with data that is updated/deleted
very often and that the files growing are the ones for the indexes, when
using B-trees.

We noticed this problem when a clean restore of a database used much
less space and the big different were in the indexes files.

In a busy 24/7 database a reindex of the indexes in a big table is not
a solution because using an ACCESS EXCLUSIVE lock for a 'long' time will
block access to data.

I have not tested if the only problem is that we use more and more space
or if performance also gets worst.

Is it possible to fix this, do we have any plans, is it better with 8.0
or 8.1?

Thanks in advance for your answers :)
--
Rafael Martinez, <r(dot)m(dot)guerrero(at)usit(dot)uio(dot)no>
Center for Information Technology Services
University of Oslo, Norway

PGP Public Key: http://folk.uio.no/rafael/

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message durumdara@mailpont.hu 2005-12-09 11:21:25 pg_dump problems
Previous Message Richard Huxton 2005-12-09 07:53:59 Re: How efficient is select currval?