Les ANALYSES VACUUM régulières sont-elles toujours recommandées sous 9.1?

J'utilise PostgreSQL 9.1 sur Ubuntu. Sont-ils VACUUM ANALYZEtoujours recommandés ou l’autovacuum suffit-il pour répondre à tous les besoins?

Si la réponse est "ça dépend", alors:

• J'ai une base de données assez longue (taille de dump compressée de 30 Go, répertoire de données de 200 Go)
• Je fais l'ETL dans la base de données, en important près de 3 millions de lignes par semaine
• Les tables avec les modifications les plus fréquentes sont toutes héritées d'une table maître, sans aucune donnée dans la table maître (les données sont partitionnées par semaine)
• Je crée des cumuls horaires, et à partir de là, des rapports quotidiens, hebdomadaires et mensuels

Je demande parce que la planification a une VACUUM ANALYZEincidence sur mes rapports. Cela dure plus de 5 heures et j'ai dû le tuer deux fois cette semaine, parce que cela affectait les importations de bases de données régulières. check_postgresne signale aucune accumulation importante dans la base de données, ce n'est donc pas vraiment un problème.

Dans les documents, autovacuum devrait également s'occuper de l'identification de la transaction. La question reste posée: ai-je encore besoin d'un VACUUM ANALYZE?

VACUUM n'est nécessaire que sur les lignes mises à jour ou supprimées dans les tables non temporaires. Évidemment, vous faites beaucoup d’insert, mais il n’est pas évident, dans la description, que vous faites aussi beaucoup de mises à jour ou de suppressions.

Ces opérations peuvent être suivies avec la pg_stat_all_tablesvue, en particulier les colonnes n_tup_updet n_tup_del. De plus, il existe une n_dead_tupcolonne qui indique, par table, combien de lignes doivent être aspirées. (Voir Surveillance des statistiques dans le document pour connaître les fonctions et les vues relatives à la collecte de statistiques).

Une stratégie possible dans votre cas serait de supprimer le VACUUM prévu, en gardant un œil sur cette vue et en vérifiant les tables qui n_dead_tupsont en train d'augmenter considérablement. Ensuite, appliquez le VACUUM agressif à ces tables uniquement. Ce sera une victoire s'il y a de grandes tables dont les lignes ne sont jamais supprimées ni mises à jour et le VACUUM agressif n'est vraiment nécessaire que sur des tables plus petites.

Mais continuez à exécuter ANALYZE pour que l'optimiseur dispose toujours de nouvelles statistiques.

Je ne vois rien dans votre question qui autovacuumne s'en occupe pas. Cela dépend en grande partie du modèle de vos activités d'écriture . Vous mentionnez 3 millions de nouvelles lignes par semaine, mais INSERT(ou COPY) généralement, ne créez pas de table et d'index. ( autovacuumne doit s’occuper que des statistiques de colonne , de la carte de visibilité et de quelques travaux mineurs). UPDATEet DELETEsont la principale cause de gonflement des tables et des index, en particulier lors du ciblage de lignes aléatoires. Je ne vois rien de cela dans votre question.

autovacuuma parcouru un long chemin et fait un excellent travail dans Postgres 9.1 ou version ultérieure. Je voudrais regarder les autovacuumparamètres . Si l'aspiration a tendance à interférer avec votre charge de travail, jetez également un coup d'oeil à "Délai d' aspiration basé sur les coûts" . L'aspiration manuelle devrait être la rare exception.

Si vous avez beaucoup de messages aléatoires UPDATE, vous pouvez définir FILLFACTORune valeur inférieure à 100, pour autoriser les mises à jour HOT immédiatement et réduire les besoins VACUUM. Plus sur les mises à jour HOT:

• Données redondantes dans les instructions de mise à jour

Notez également que les tables temporaires ont besoin de manuel VACUUM& ANALYZE. Je cite le manuel surCREATE TABLE :

Le démon autovacuum ne peut pas accéder et ne peut donc pas aspirer ou analyser des tables temporaires. Pour cette raison, les opérations de vide et d'analyse appropriées doivent être effectuées via des commandes SQL de session. Par exemple, si une table temporaire doit être utilisée dans des requêtes complexes, il est conseillé de l'exécuter ANALYZEsur la table temporaire après son remplissage.

Bien que je convienne que l’utilisation des fonctionnalités automatiques est préférable au lieu de l’utiliser dans toute la base de données, dans la plupart des cas, un réglage par table est nécessaire.

Je ne suis pas tout à fait d'accord avec le choix de conception de postgres pour lier ensemble le vide et l'analyse. J'ai vu plusieurs cas dans lesquels des bases de données faisant beaucoup d'insert / mises à jour mais peu de suppressions ne sont jamais analysées et commencent à mal fonctionner.

La solution consiste à accéder aux tables fortement utilisées et sujettes aux requêtes volumineuses, puis à définir les paramètres d'analyse automatique pour ces tables de manière à ce qu'elles soient analysées une ou deux fois par jour.

Vous pouvez accéder aux paramètres par table dans l’interface graphique dans l’onglet Aspiration automatique et y afficher des paramètres d’analyse que vous pouvez définir indépendamment du vide.

Les paramètres se retrouvent dans la table des reloptions et peuvent être vus avec la requête

SELECT c.relname, c.reloptions FROM pg_class c where reloptions is not null

et une valeur d'échantillon d'une analyse agressive pourrait être

{autovacuum_enabled=true,autovacuum_analyze_threshold=10,autovacuum_analyze_scale_factor=.01}

Pour voir quand la dernière fois que vos tables ont été analysées automatiquement

select 
    relname, 
    n_dead_tup, 
    n_tup_ins, 
    n_tup_upd, 
    n_tup_del, 
    last_autoanalyze, 
    autoanalyze_count 
from pg_stat_user_tables 
where last_autoanalyze is not null 
order by last_autoanalyze desc;