Размер базы данных PostgreSQL (размер табличного пространства) намного больше, чем рассчитанная общая сумма отношений

Question

Привет всем,

Я вижу очень большую разницу между фактическим размером базы данных (на жестком диске и отображаемым вызовом pg_database_size()) и размером, вычисленным путем суммирования общих размеров отношений, полученных с помощью pg_total_relation_size()

Первый - 62G, а последний - 16G (правильная разница удаленных данных из самой большой таблицы)

Вот упрощенный запрос, который может показать эту разницу в моей системе:

select current_database(),
       pg_size_pretty( sum(total_relation_raw_size)::bigint ) as calculated_database_size,
       pg_size_pretty( pg_database_size(current_database()) ) as database_size   
  from (select pg_total_relation_size(relid) as total_relation_raw_size
          from pg_stat_all_tables -- this includes also system tables shared between databases
         where schemaname != 'pg_toast' 
       ) as stats;

Кажется, там есть какие-то висячие данные. Когда возникла такая ситуация, после того, как мы полностью сбросили кучу неиспользуемых данных из этой БД.

P.S .: Я полагаю, что это было какое-то повреждение базы данных ... Единственный выход из этой ситуации - переключиться на базу данных с горячим резервированием ...

Answer 1

LOB очень важны, так как BobG пишет, так как они не удаляются, когда удаляются строки таблицы вашего приложения (содержащие OID).

Они не будут удалены процессом VACUUM автоматически,только вы запустили VACUUMLO для них.

Vacuumlo удалит все не связанные объекты из базы данных.

Пример вызова:

vacuumlo -U postgres -W -v <database_name>

(я включил только -v чтобы сделать вакуум более подробным, чтобы вы увидели, сколько больших объектов он удаляет)

После того, как вакуумные файлы удалены, вы можете запустить VACUUM FULL (или разрешить запуск процесса автоматического вакуума).

Answer 2

Когда возникла такая ситуация, после того, как мы сбросили и полностью откачали много неиспользуемых данных из этой БД.

У меня был похожий опыт: 3 ГБ дБ с большим количеством динамических данных, которые перешли в 20 ГБв течение месяца или около того.Удаление / очистка проблемных таблиц вручную, похоже, не дает эффекта ... А потом мы просто сделали окончательную

VACUUM FULL ANALYZE 

На ВСЕЙ БД ... и она упала вдвое меньше.

Это заняло 4 часа, так что будьте осторожны с этим.

Answer 3

У вас есть неиспользованные рабочие места?

Если у вас есть что-то вроде этого:

CREATE TABLE bigobjects (
    id BIGINT NOT NULL PRIMARY KEY,
    filename VARCHAR(255) NOT NULL,
    filecontents OID NOT NULL
);

с последующим:

\lo_import '/tmp/bigfile'
11357
INSERT INTO bigobjects VALUES (1, 'bigfile', 11357);
TRUNCATE TABLE bigobjects;

У вас все еще будет большой объект (id 11357) в базе данных.

Вы можете проверить таблицу системного каталога pg_catalog.pg_largeobject для всех крупных объектов в вашей базе данных (рекомендуйте SELECT DISTINCT loid FROM pg_catalog.pg_largeobject, если вы не хотите видеть все ваши данные больших объектов как восьмеричные.)

Если вы вычистите все неиспользуемые большие объекты и сделаете ВАКУУМНЫЙ ПОЛНЫЙ, вы должны увидеть значительное сокращение хранилища. Я только что попробовал это на личной базе данных разработчика, которую я использовал, и увидел уменьшение размера с 200 МБ до 10 МБ (как сообщает pg_database_size (current_database ()).)

Answer 4

Ваш запрос специально отсеивает таблицы pg_toast, которые могут быть большими.Посмотрите, избавится ли от того, где schemaname != 'pg_toast' даст вам более точный ответ.