La réponse courte est que le stockage de la base de données est plus optimisé pour la vitesse que pour l'espace.
Par exemple, si vous avez inséré 100 lignes dans une table, puis supprimé toutes les lignes avec un ID impair, le SGBD pourrait écrire une nouvelle table avec seulement 50 lignes, mais il est plus efficace de simplement marquer les lignes supprimées comme espace libre et réutilisez-les lors de la prochaine insertion d'une ligne. Par conséquent, la table occupe deux fois plus d'espace que ce qui est actuellement nécessaire.
L'utilisation par Postgres de "MVCC", plutôt que de verrouiller, pour la gestion des transactions rend cela encore plus probable, car une mise à jour implique généralement l'écriture d'une nouvelle ligne dans le stockage, puis le marquage de l'ancienne ligne supprimée une fois qu'aucune transaction ne la regarde.
En vidant et en restaurant la base de données, vous recréez une base de données sans tout cet espace libre. C'est essentiellement ce que le VACUUM FULL commande le fait - elle réécrit les données actuelles dans un nouveau fichier, puis supprime l'ancien fichier.
Il existe une extension distribuée avec Postgres appelée pg_freespace
qui vous permet d'examiner certains de ces éléments. par exemple. vous pouvez répertorier la taille de la table principale (sans compter les index et les colonnes stockées dans des tables "TOAST" distinctes) et l'espace libre utilisé par chaque table avec ce qui suit :
Select oid::regclass::varchar as table,
pg_size_pretty(pg_relation_size(oid)/1024 * 1024) As size,
pg_size_pretty(sum(free)) As free
From (
Select c.oid,
(pg_freespace(c.oid)).avail As free
From pg_class c
Join pg_namespace n on n.oid = c.relnamespace
Where c.relkind = 'r'
And n.nspname Not In ('information_schema', 'pg_catalog')
) tbl
Group By oid
Order By pg_relation_size(oid) Desc, sum(free) Desc;
