Удаляются ли мертвые ряды чем-то еще, кроме вакуума? - PullRequest
Новая
       27

Удаляются ли мертвые ряды чем-то еще, кроме вакуума?

0 голосов
/ 03 июля 2018

В журнале PostgreSQL 9.3.19 я вижу следующие две последовательные записи для автоочистки данной таблицы: 

2018-06-29 17:24:06 CDT 13177 14/870454 0 LOG:  automatic vacuum of table "openbravo.public.ad_session_status": index scans: 0
    pages: 0 removed, 235 remain
    tuples: 0 removed, 14669 remain
    buffer usage: 1090 hits, 673 misses, 4 dirtied
    avg read rate: 6.745 MB/s, avg write rate: 0.040 MB/s

- 

2018-06-29 17:24:55 CDT 13529 40/699086 0 LOG:  automatic vacuum of table "openbravo.public.ad_session_status": index scans: 0
    pages: 0 removed, 235 remain
    tuples: 0 removed, 13039 remain
    buffer usage: 1143 hits, 663 misses, 0 dirtied
    avg read rate: 3.086 MB/s, avg write rate: 0.000 MB/s

Все автовакуумы регистрируются : log_autovacuum_min_duration=0.

Между ними нет других ручных пылесосов.

Как может получиться, что если ни один из этих двух вакуумов не удаляет мертвый кортеж, оставшееся количество кортежей уменьшается после 2-го? Есть ли в PostgreSQL другие способы удаления мертвых строк?

1 Ответ

0 голосов
/ 04 июля 2018

Одно объяснение может быть ГОРЯЧИЕ обновления .

Если в блоке таблицы есть место и обновленный столбец не проиндексирован, PostgreSQL поместит новую версию строки в тот же блок, что и оригинал, и создаст & ldquo; цепочку HOT & rdquo; где старая версия строки указывает на новую. Это позволяет PostgreSQL пропускать обновление всех индексов, которые указывают на эту строку таблицы.

Помимо уменьшения количества операций ввода-вывода во время UPDATE, HOT также позволяет удалять старые версии строк & ldquo; на лету & rdquo;: при каждом посещении страницы, которая почти заполнена и может быть получена необходимая блокировка, PostgreSQL будет выполнять & ldquo; микро-вакуум & rdquo; на этом блоке путем его реорганизации.

Это то, что может вызвать наблюдаемое сокращение кортежей.

Чтобы поддержать или опровергнуть эту теорию, выполните следующий запрос: 

SELECT n_tup_upd, n_tup_hot_upd
FROM pg_stat_user_tables
WHERE schemaname = 'public' AND relname = 'ad_session_status';

Если n_tup_hot_upd больше нуля, у нас есть дело.

...