Je jouais avec VACUUM
et j'ai remarqué un comportement inattendu où SELECT
les lignes d'une table semblent réduire le travail VACUUM
à faire par la suite.
Données de test
Remarque: le vide automatique est désactivé
CREATE TABLE numbers (num bigint);
ALTER TABLE numbers SET (
autovacuum_enabled = 'f',
toast.autovacuum_enabled = 'f'
);
INSERT INTO numbers SELECT generate_series(1, 5000);
Essai 1
Maintenant, nous exécutons une mise à jour sur toutes les lignes,
UPDATE numbers SET num = 0;
Et quand nous courons, VACUUM (VERBOSE) numbers;
nous obtenons,
INFO: vacuuming "public.numbers"
INFO: "numbers": removed 5000 row versions in 23 pages
INFO: "numbers": found 5000 removable, 5000 nonremovable row versions in 45 out of 45 pages
DETAIL: 0 dead row versions cannot be removed yet, oldest xmin: 6585
There were 0 unused item pointers.
Essai 2
Maintenant, nous en émettons un autre UPDATE
, mais cette fois, nous en ajoutons un SELECT
après,
UPDATE numbers SET num = 1;
SELECT * FROM numbers;
Et quand nous courons, VACUUM (VERBOSE) numbers;
nous obtenons,
INFO: vacuuming "public.numbers"
INFO: "numbers": removed 56 row versions in 22 pages
INFO: "numbers": found 56 removable, 5000 nonremovable row versions in 45 out of 45 pages
DETAIL: 0 dead row versions cannot be removed yet, oldest xmin: 6586
There were 56 unused item pointers.
Que se passe-t-il exactement ici? Pourquoi la deuxième version que j'exécute, après avoir SELECT
supprimé les tuples morts des pages qu'elle visite, tout comme le VACUUM
fait?
J'exécute Postgres 11.3 sur macOS 10.14.5.