La page "how-to-vacuum-postgresql" référencée dans la question donne de très mauvais conseils lorsqu'elle recommande VACUUM FULL . Tout ce qui est nécessaire est un vide de la base de données complète, qui est simplement un VACUUM s'exécute en tant que superutilisateur de la base de données sur l'ensemble de la base de données (c'est-à-dire que vous ne spécifiez aucun nom de table).
A VACUUM FULL fonctionne différemment selon la version, mais il élimine tout l'espace dans les fichiers du tas qui est conservé par la base de données pour une réutilisation rapide, et le libère pour le système d'exploitation. Cela peut être beaucoup plus lent que le minimum nécessaire pour revenir à une base de données utilisable, par ordre de grandeur. Et puisque toutes les insertions ou mises à jour après la VACUUM FULL nécessitent des appels au système d'exploitation pour réallouer de l'espace à la base de données, cela peut entraîner un ralentissement de l'exécution par la suite, à moins que votre base de données ne soit très gonflée. (Bien que, si vous avez désactivé l'autovacuum, elle pourrait être dans un état horrible, mais vous voulez probablement vous remettre sur pied d'abord, et régler cela plus tard).
Un autre problème avec VACUUM FULL avant la version 9.0 est que, bien qu'elle élimine le gonflement des fichiers de tas d'une table, elle tend à augmentation de dans ses fichiers d'index, parfois de façon spectaculaire. Si vous émettez un VACUUM FULL vous devez normalement le faire suivre d'un REINDEX pour remettre les index en bon état.
La page mentionnée dans la question ne tient pas compte non plus des conseils donnés dans la documentation de PostgreSQL à l'adresse suivante http://www.postgresql.org/docs/8.3/interactive/routine-vacuuming.html#VACUUM-FOR-WRAPAROUND pour utiliser le mode mono-utilisateur :
puisque le système n'exécutera pas de commandes une fois qu'il sera passé dans le mode mode d'arrêt de sécurité, la seule façon d'y parvenir est d'arrêter le serveur et d'utiliser un backend mono-utilisateur pour exécuter VACUUM. Le mode d'arrêt n'est n'est pas appliqué par un backend mono-utilisateur. Consultez la page de référence postgres pour plus de détails sur l'utilisation d'un backend mono-utilisateur.
Comme d'autres l'ont mentionné, il n'y a pratiquement aucun cas d'utilisation où la désactivation de l'autovacuum est bénéfique. Il peut être utile de supplément l'activité d'autovacuum avec des aspirateurs explicites sur les grandes tables, ou vous pouvez vouloir ajuster la configuration d'autovacuum, mais vraiment -- ne le désactivez pas ou vous verrez un gonflement qui sape les performances et vous rencontrerez périodiquement des problèmes d'enveloppement d'ID de transaction. Les personnes qui remarquent une baisse de performance lorsque autovacuum effectue la maintenance ont parfois l'instinct de le rendre moins agressif dans son déclenchement, mais cela est généralement contre-productif. Il est généralement préférable d'ajuster les paramètres de limitation des coûts d'autovacuum pour rythmer le travail, plutôt que de le laisser négliger les tables qui ont besoin de maintenance.
