L'annulation d'un processus (AUTO) VACUUM dans PostgreSQL rend-elle tout le travail inutile?

À certaines occasions, et après avoir fait un massif update, insertou à deletepartir d'une table, j'ai commencé un VACUUM FULL ANALYZEpour m'assurer que la DB ne se gonflait pas trop. Le faire dans une base de données de production m'a permis de découvrir que ce n'était pas une bonne idée, car je pouvais bloquer la table pendant une longue période. J'ai donc annulé le processus, peut-être essayé juste VACUUM(pas complètement) ou laissé AUTOVACUUMfaire plus tard ce qu'il peut faire.

La question est: si j'arrête un VIDE ou un AUTOVACUUM "à mi-chemin", tout le traitement déjà fait est-il perdu?

Par exemple, si VACUUMj'ai déjà trouvé 1 M de lignes mortes et que je l'arrête, toutes ces informations sont-elles perdues? VACUUM fonctionne-t-il de manière entièrement transactionnelle ("tout ou rien", comme un très bon nombre de processus PostgreSQL)?

Si VACUUM peut être interrompu en toute sécurité sans que tout le travail soit perdu, y a-t-il un moyen de rendre le vacuumtravail incrémentiel? [Travaillez pendant 100 ms, arrêtez, attendez 10 ms pour permettre de ne pas bloquer le reste du monde ... et ainsi de suite]. Je sais que vous pouvez faire une partie de cela en ajustant les paramètres du vide automatique, mais je pense à pouvoir contrôler cela par programme, pour pouvoir le faire à certains moments / dans certaines conditions.

REMARQUE: Arrêter / annuler / tuer le processus signifie dans ce contexte:

Si vous utilisez pgAdmin, appuyez sur le bouton "Annuler la requête".
Si vous travaillez par programmation, appelez pg_cancel_backend ().

Je suppose que les deux sont équivalents. Je n'ai utilisé aucune commande kill au niveau shell / système.

— joanolo
source

Le travail effectué par un VIDE interrompu sera entièrement perdu, car il reviendra simplement à utiliser la version précédente de la table et jettera la version en cours de la table.

Le travail effectué par un ASPIRATEUR régulier (non-PLEIN) peut ne pas être entièrement perdu. Il nettoie les index par lots, et tous les lots qui ont été entièrement nettoyés n'auront pas besoin d'être nettoyés à nouveau. Ils devront encore être inspectés à nouveau, mais seront trouvés déjà propres la prochaine fois. Ainsi, vous pourriez économiser des E / S d'écriture qui n'auront pas besoin d'être répétées.

— jjanes
source

J'aimerais plus de détails à ce sujet, en particulier sur l'autovacuum. J'ai des serveurs occupés avec de nombreuses bases de données et parfois les aspirateurs peuvent prendre beaucoup de temps. Lorsque cela se produit, la création d'un nouvel index, par exemple, est impossible car l'autovacuum a un verrou. Dans certains cas, il serait idéal de supprimer l'autovacuum et d'appliquer l'index, puis, espérons-le, lorsque l'autovacuum s'exécute à nouveau, il n'a pas à fonctionner presque aussi longtemps. Est-il possible de voir les détails de ce que l'autovacuum a fait / fait sur une table et des index?

— Kurt Koller

9.6 a introduit une vue pour suivre les progrès du vide: postgresql.org/docs/current/static/progress-reporting.html . Je ne l'ai pas joué moi-même, alors je ne sais pas si cela fonctionnera pour vous. Autovacuum devrait céder automatiquement à la serrure, sauf si cela est fait pour le bouclage. Les paramètres par défaut de l'autovacuum sont fortement limités, il est donc possible qu'il ne s'exécute pas plus rapidement la prochaine fois simplement parce qu'il est limité à la même vitesse. Je mets régulièrement vacuum_cost_page_hitet vacuum_cost_page_missà zéro.

— jjanes