Eu estava brincando VACUUM
e notei algum comportamento inesperado em que SELECT
as linhas de uma tabela parecem reduzir o trabalho que VACUUM
deve ser feito depois.
Dados de teste
Nota: o vácuo automático está desativado
CREATE TABLE numbers (num bigint);
ALTER TABLE numbers SET (
autovacuum_enabled = 'f',
toast.autovacuum_enabled = 'f'
);
INSERT INTO numbers SELECT generate_series(1, 5000);
Julgamento 1
Agora, executamos uma atualização em todas as linhas,
UPDATE numbers SET num = 0;
E quando corremos VACUUM (VERBOSE) numbers;
, chegamos,
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.
Julgamento 2
Agora emitimos outro UPDATE
, mas desta vez adicionamos um SELECT
depois,
UPDATE numbers SET num = 1;
SELECT * FROM numbers;
E quando corremos VACUUM (VERBOSE) numbers;
, chegamos,
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.
O que exatamente está acontecendo aqui? Por que a segunda versão que eu executo, após SELECT
remover tuplas mortas das páginas visitadas, é semelhante a VACUUM
isso?
Estou executando o Postgres 11.3 no macOS 10.14.5.