И вот после

df -h
имеем 19G свободного пространства на диске

Позвали местного колдуна, который применил

vacuum full table; -- где table большая очень фрагментированная таблица

и после
df -h
имеем 12G свободного пространства на диске !!!
(Колдун на костре...)

Кто-то из староверов DBA, можете подсказать почему vacuum full не увеличил свободный размер диска?

Он же вроде должен был переписать данные в новую таблицу, а старую удалить?
Что делать? Help!

Maxim Boguk,

PostgreSQL 10.9 (Ubuntu 10.9-1.pgdg16.04+1) on x86_64-pc-linux-gnu

Maxim Boguk, спасибо что с нами, бедолагами ...

Пока могу сказать, что checkpoint никак, как заклятие не работает ...

В data_directory второй таблицы с размером 16G в каталоге базы нет, т.е. видимо старая удалилась.

du base/16384/* | sort -n

...
1048580 base/16384/234649
1048580 base/16384/234649.1
1048580 base/16384/234649.2
1048580 base/16384/234649.3
1048580 base/16384/234649.4
1048580 base/16384/234649.5
1048580 base/16384/234649.6
1048580 base/16384/234649.7
1048580 base/16384/234649.8
1048580 base/16384/234649.9
1048580 base/16384/78263

Но куда дисковая память ушла? Где-то ведь лежит результат vacuum full table; кроме этих файлов?
(Это вопрос следующего поста)

>>может быть много причин почему вот так вот...

Пожалуйста, если можно уточните, в каком порядке (или контексте) должна была выполняться команда

1. ---
2. ---
...
vacuum full some_table;
...
n.
чтобы старая таблица some_table "поджалась" и "переехала" в новую таблицу с тем же названием, при этом
увеличив размер физической памяти на диске ?

>>Но куда дисковая память ушла? Где-то ведь лежит результат vacuum full table; кроме этих файлов?
>>(Это вопрос следующего поста)

Поста не будет, память ушла в /pg_wal

Но вот насколько эффективно сработал vacuum full ? как проверить ?

Ок, всем большое спасибо.

Действительно, бага нет, колдун жив - оказался из рода Торгариенов ...