-----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-----
<<inline: space_usage.png>>
---------------------------(end of broadcast)--------------------------- TIP 4: Don't 'kill -9' the postmaster
