Обсуждение: vacuum is not sufficient?

Hello list!

I'm using postgresql     7.3.2r1-6.woody
from http://people.debian.org/~elphick/debian
in some production enviroment.

I had in the past with the stable release of postgres in debian woody a
problem about
"enlarging tables". In particular session tables with a lot of traffic
became from some Megs to a couple of gigs...
After upgrade to newer version that problem now is returned after about 1-2
month of working...

this is the "tipical" vacuum output that I have in those tables...

INFO:  --Relation public.active_sessions_split--
INFO:  Index active_sessions_split_pkey: Pages 91838; Tuples 5381: Deleted 31.
        CPU 4.26s/0.47u sec elapsed 135.47 sec.
INFO:  Index k_asp_changed: Pages 46192; Tuples 5381: Deleted 31.
        CPU 2.32s/0.25u sec elapsed 34.94 sec.
INFO:  Removed 31 tuples in 6 pages.
        CPU 0.00s/0.00u sec elapsed 0.01 sec.
INFO:  Pages 78376: Changed 4, Empty 0; Tup 5381: Vac 31, Keep 0, UnUsed 615471.
Total CPU 9.93s/1.13u sec elapsed 186.68 sec.

-rw-------    1 postgres postgres     724M Aug  8 18:47 309922
(the table file)

and with vacuum , vacuum full nothing change...

and the same problem in other db with high load average tables...

it's a bug or what? some ideas?

Thanks in advance!

Matteo

Matteo <sgala@sgala.com> writes:
> INFO:  --Relation public.active_sessions_split--
> INFO:  Index active_sessions_split_pkey: Pages 91838; Tuples 5381: Deleted 31.
>         CPU 4.26s/0.47u sec elapsed 135.47 sec.
> INFO:  Index k_asp_changed: Pages 46192; Tuples 5381: Deleted 31.
>         CPU 2.32s/0.25u sec elapsed 34.94 sec.
> INFO:  Removed 31 tuples in 6 pages.
>         CPU 0.00s/0.00u sec elapsed 0.01 sec.
> INFO:  Pages 78376: Changed 4, Empty 0; Tup 5381: Vac 31, Keep 0, UnUsed 615471.
> Total CPU 9.93s/1.13u sec elapsed 186.68 sec.

I'd try a dump/reload or CLUSTER to get the table back down to a
reasonable size.  In future, try vacuuming it more often.

            regards, tom lane