🛠️ UPDATE меняет одно поле. Почему HOT почти не срабатывает?

Условная статистика:

n_tup_upd = 18 400 000
n_tup_hot_upd = 920 000
n_dead_tup = 3 700 000

При UPDATE PostgreSQL создаёт новую версию строки. HOT позволяет не добавлять для неё записи в обычные индексы, но нужны два условия:

— обновление не меняет данные, на которые ссылаются обычные индексы;
— новая версия помещается на той же heap-странице.

Например:

UPDATE orders
SET processing_status = 'completed'
WHERE id = :id;

Если processing_status используется обычным, составным, partial или expression index, изменение обычно исключает HOT.

Исключение — summarizing indexes: в основной поставке PostgreSQL это BRIN. Они не запрещают HOT тем же способом, хотя их сводные данные могут обновляться.

Если индекс обновлять не нужно, остаётся второй вопрос: хватает ли места на исходной странице.

Более низкий table fillfactor оставляет запас и может повысить вероятность HOT. Но это не гарантия: менее плотное размещение увеличивает число страниц, а изменение параметра само по себе не переразмещает все существующие строки.

Что проверить:

— какие запросы создают основной поток UPDATE;
— какие данные используются индексами;
— долю n_tup_hot_upd в n_tup_upd;
— при доступности — n_tup_newpage_upd;
— fillfactor и размеры отношений в динамике;
— сопоставимый интервал статистики.

n_dead_tup — оценка, а не точное измерение bloat.
VACUUM освобождает место dead versions для повторного использования, но не превращает будущие обновления в HOT автоматически.

Вывод: низкая доля HOT — начало диагностики, а не команда удалить индекс, снизить fillfactor или чаще запускать VACUUM.

🔹🔹🔹🔹