Мертвые кортежи не собираются командой VACCUM FULL - PullRequest
0 голосов
/ 23 апреля 2019

Извинения, это длинный пост и вопрос & postgres новичок

Хотелось бы узнать, как работает postgres VACCUM и VACCUM FULL , что предпочтительно для 700 ГБ архивирования таблиц без простоев.

ВАККУМ ПОЛНЫЙ СЛУЧАЙ:

В этом случае похоже, что память освобождается для ОС после выполнения команды полного заполнения, , но n_dead_tuples остаются неизменными.

Будет ли этот n_dead_tup повторно использоваться при следующей вставке / обновлении / удалении?

ШАГИ:

CREATE TABLE Foo (
  id SERIAL PRIMARY KEY,
  x  INTEGER NOT NULL
);

// CREATE TABLE

INSERT INTO Foo (x) VALUES (generate_series(1,1000000));

// INSERT 0 1000000

SELECT pg_size_pretty(pg_relation_size('foo'));

// 35 MB

SELECT n_dead_tup FROM pg_stat_user_tables where relname = 'foo';

// 0

UPDATE Foo SET x = x + 1;

// UPDATE 1000000

SELECT pg_size_pretty(pg_relation_size('foo'));

// 69 MB

SELECT n_dead_tup FROM pg_stat_user_tables where relname = 'foo';

// 1000000

VACUUM FULL VERBOSE foo;

// INFO:  vacuuming "public.foo"
// INFO:  "foo": found 1000000 removable, 1000000 nonremovable row versions in 8850 pages
// DETAIL:  0 dead row versions cannot be removed yet.
// CPU 0.07s/0.67u sec elapsed 0.76 sec.
// VACUUM

 SELECT pg_size_pretty(pg_relation_size('foo'));

// 35 MB

SELECT n_dead_tup FROM pg_stat_user_tables where relname = 'foo';

// 1000000

ВАКУМНЫЙ СЛУЧАЙ

ШАГИ:

То же, что и вышеописанные шаги, за исключением VACCUM FULL, необходимо выполнить следующие команды. В этом случае похоже, что мертвые кортежи удаляются, но размер не передается в ОС.

VACUUM VERBOSE foo;

// INFO:  vacuuming "public.foo"
// INFO:  scanned index "foo_pkey" to remove 1000000 row versions
// DETAIL:  CPU 0.01s/0.27u sec elapsed 0.34 sec.
// INFO:  "foo": removed 1000000 row versions in 4425 pages
// DETAIL:  CPU 0.00s/0.02u sec elapsed 0.02 sec.
// INFO:  index "foo_pkey" now contains 1000000 row versions in 8237 pages
// DETAIL:  1000000 index row versions were removed.
// 0 index pages have been deleted, 0 are currently reusable.
// CPU 0.00s/0.00u sec elapsed 0.00 sec.
// INFO:  "foo": found 1000000 removable, 1000000 nonremovable row versions in 8850 out of 8850 pages
// DETAIL:  0 dead row versions cannot be removed yet.
// There were 0 unused item pointers.
// Skipped 0 pages due to buffer pins.
// 0 pages are entirely empty.
// CPU 0.03s/0.52u sec elapsed 0.61 sec.
// VACUUM

SELECT pg_size_pretty(pg_relation_size('foo'));

// 69 MB

SELECT n_dead_tup FROM pg_stat_user_tables where relname = 'foo';

// 0

IS АВТО ВАКУУМ ЭКВИВАЛЕНТ * ВАКУУМ ?

Заранее спасибо.

1 Ответ

1 голос
/ 23 апреля 2019

Простой VACUUM обычно не освобождает дисковое пространство, как объяснено в документации :

[...] Однако, дополнительное пространство не возвращается в рабочее состояние.система (в большинстве случаев);он просто доступен для повторного использования в той же таблице.[...]

Для VACUUM FULL он отличается, поскольку в основном перезаписывает данные всей таблицы, как объяснено в документации 1012 *:

[...] Этот метод также требует дополнительного дискового пространства, так как он записывает новую копию таблицы и не освобождает старую копию до завершения операции.[...]

При переписывании данные записываются физически близко друг к другу, без дыр, вызванных старыми версиями строк.Растущее дисковое пространство является одним из недостатков MVCC , реализованных в PostgreSQL, и требует тщательного наблюдения и настройки для больших таблиц и таблиц с большими объемами обновлений.

Автоматический вакуум будет Никогда не выполняйте VACUUM FULL, так как это заблокирует любую другую активность в таблице / отношении, с которой он работает, с непредсказуемыми последствиями для любого подключенного приложения.

Если вы столкнетесь с проблемами здесь, вы должны начать думать оПо крайней мере, разделение таблицы таким образом, чтобы влияние обслуживания VACUUM FULL оставалось низким (поскольку раздел имеет малый размер) или даже лучше, позволяет просто удалить раздел вместо необходимости перезаписи.Но это действительно зависит от семантики данных, которые вы храните и обновляете.

...