Please keep replies copied to the list so that others can learn from and
contribute to the discussion. I don't remember where this was, but it looks
like general is probably reasonable.
On Mon, May 08, 2006 at 15:02:20 +0100,
Joao Miguel Ferreira <jmf@estg.ipvc.pt> wrote:
> Bruno and all,
>
> > There are a couple of possibilities worth checking. One is that there aren't
> > idle transactions staying open for a long time. These would prevent vacuum
> > from removing deleted rows as these transactions could still see them.
>
> I've checked that. No open transactions.
>
> > Another possibility is that the FSM is too low and there isn't enough space to
> > track all of rows that can be recovered. (Vacuuming more often will also
> > reduce the needed FSM setting.)
> Didn't check this!
>
> > A third possible issue is index bloat, which
> > can happen on older versions (7.4ish) of Postgres where key values increase (or
> > decrease) montonicly.
>
> REINDEX(ing) the indexes causes a sudden drop in filesystem usage, but
> after a while it size gets back to the value when it dropped and still
> grwoing (sime 100 to 300 Bytes/minute).
>
> Yes, my tables contains ever grwoing values afected by a UNIQUE
> constraint.
>
> What would I do next ?
>
> jmf
> (Pg is 7.2, rpm install, Fedora Core 3)
7.2 is subject to index bloat for indexes where the column increase monotonicly
and old values are deleted. In the short run you will want to schedule
regular reindexes.
In the long run, you should upgrade. 7.2 is essentially without support. I
beleive there is still a RHEL version using it that is in support, so a
critical fix might get back ported.