Re: check point segments leakage ?

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Matthew T. O'Connor wrote:

| Gaetano Mendola wrote:
|
|> Well, today I stop the pg_autovacuum and I did a vacuum full and I
|> reindexed
|> all big tables and other 500 MB were reclamed. Could be the pg_autovacuum
|> running yesterday the responsible for these 500MB not reclamed during
|> a vacuum full and reindex already performed yesterday ?
|
|
| Probably not. Most of the time pg_autovacuum is just sleeping. If you
| happened to fun a VACUUM FULL while pg_autovacuum was running a vacuum,
| there might have been a conflict on the tabke pg_autovacuum was working
| with at the time.
|
| Also, are you sure that the space wasn't reclaimed yesterday after the
| VACUUM FULL? It could be that your tables have grown 500M since then.
| Remember, the minimum table size (the size after a VACUUM FULL) is not
| necessarilly the optimial size. Postgresql will almost always need to
| reallocate the space that was reclaimed by VACUUM FULL.

I'm pretty sure, see the attached graph. Each morning at 7 a script stop
the autovacuum, vacuum full the database and reindex the eavy updated tables
and restart of course the autovacuum. Note also that for all the day I didn't
have the usual disk usage increment.

|> I'm wandering if will be possible in the 7.5 start and stop the the
|> autovacuum integrated in the backend.
|
|
| Yes (at least the patch waiting to be applied to CVS HEAD does) in order
| to stop autovacuum you will have to edit the autovac option in
| postgresql.conf and HUP the postmaster.

This is a good news.

Regards
Gaetano Mendola

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFA/o2Z7UpzwH2SGd4RAi38AKCO7XqClR/+X5b8szVJwbREC50HrQCg5M8n
R5ODgRU05IGnnS1YaK4afIk=
=ftFY
-----END PGP SIGNATURE-----