Taille de la base de données réduite après la sauvegarde sur PostgreSQL 8.3 et la restauration dans PostgreSQL 9.4

J'ai fait une pg_dumpsur une base de données JIRA que j'hébergeais sur un serveur PostgreSQL 8.3. La taille de la base de données après vacuum fullétait 217132652(environ 207 Mo).

J'ai ensuite restauré cette base de données JIRA sur un serveur PostgreSQL 9.4 avec la commande suivante:

$ psql -X -v ON_ERROR_STOP=1 -d jira2 -U jira -h localhost < jiradb2017_03_12.sql

Je suppose que la restauration se ON_ERROR_STOP=1terminera sur toute erreur depuis que je l'ai utilisé , mais le script SQL s'est terminé correctement (malgré certains avertissements non liés à la restauration des données).

Je me suis retrouvé avec une base de données d'une taille de 158019348(environ 151 Mo).

Alors, quelle est l'histoire ici? Puis-je supposer que la base de données a été restaurée avec succès et que PostgreSQL a optimisé son moteur de stockage (entre les versions 8.3 et 9.4) et utilise l'espace plus efficacement?

Lorsque vous restaurez une base de données, vous avez toutes les informations sur elle , sans espace vide entre les lignes (ou dans les index), sauf si certains paramètres spécifiques sont en place (essentiellement: FILLFACTORpour les tables et FILLFACTORpour les index ).

D'un autre côté, lorsque votre base de données est utilisée depuis un certain temps et que vous avez eu votre part d'insertions, de mises à jour et de suppressions, l'espace libre inutilisé apparaît . Cela est dû à la façon dont PostgreSQL et Multiversion Concurrency Control, alias MVCC fonctionnent. MVCC permet moins de verrouillages, ce qui signifie essentiellement que vous gagnez du temps . Mais vous payez un prix en termes d' espace :

1. Chaque UPDATEéquivaut à un INSERTensemble avec un DELETE, avec la surcharge (au moins en termes d'espace utilisé) associée aux deux.
2. Lorsque plusieurs transactions sont en cours d'exécution, et que chacune est INSERTing, UPDATEing ou DELETEing, vous disposez simultanément de plusieurs copies de chaque ligne impliquée.
3. L'espace alloué à ces versions de ligne ne sera pas libéré immédiatement après la validation, et pendant un certain temps, sera l' espace inutilisé dans les fichiers où vos données de table (et index) sont stockées.

Autovacuum prend soin de rendre cet espace réutilisable par défaut, ou vous pourriez avoir une procédure spécifique pour passer l'aspirateur de routine .

Ce fait peut déjà expliquer le changement de taille.

Des optimisations entre les versions ont probablement également eu lieu; et peut expliquer de nouvelles améliorations. Des optimisations auraient également pu être faites pour la vitesse et non pour la taille, et la taille réelle pourrait en fait augmenter d'une version à l'autre. Je ne connais vraiment pas les détails pour pouvoir le dire; bien que le commentaire de @Erwin indique que les modifications qui font rétrécir vos tables et celles qui font gonfler (grandir) vos tables ont eu lieu depuis la version 8.3.

Pour distinguer les deux effets, si vous êtes curieux, vous pouvez simplement, comme le suggère @Jack Douglas, restaurer votre base de données sur 8.3. Il diminuera probablement sa taille. S'il diminue à moins de 151 Mo (une taille inférieure à celle que vous obtenez avec la version 9.4), la suppression de l'espace inutilisé a fait rétrécir votre base de données et le changement de version a en fait fait croître votre base de données.

Pour une meilleure compréhension de MVCC, regardez la présentation de Bruce Momjian .