Внутристраничная очистка и HOT

Возьмём таблицу с индексом и обновим неиндексируемое поле. Что должно произойти по той модели, которую мы построили раньше?

CREATE TABLE acc (id int PRIMARY KEY, balance int, note text);

CREATE INDEX acc_note_idx ON acc (note);

INSERT INTO acc VALUES (1, 100, 'alice');

UPDATE acc SET balance = 200 WHERE id = 1;

Наивно: появилась новая версия строки с новым ctid. Значит, оба индекса - и acc_pkey, и acc_note_idx - должны получить новую запись, указывающую на этот ctid. Два индекса на одно обновление, хотя ни id, ни note не менялись.

Это и была боль ранних версий: таблица с пятью индексами платила пятью записями в индексы за каждый UPDATE, даже когда менялось одно число. Индексы росли, как на дрожжах, и VACUUM едва успевал.

Логика подсказывает: раз id и note те же, старые записи в индексах всё ещё корректны - они и так указывают «куда-то в эту строку». Надо только научить индекс находить актуальную версию, пройдя по цепочке внутри страницы. Именно это и делает HOT.

HOT-обновление срабатывает при двух условиях одновременно:

1. ни одна колонка, входящая хоть в один индекс, не изменилась;
2. новая версия строки помещается в ту же страницу, где лежит старая.

Когда оба выполнены, PostgreSQL не пишет в индексы ничего. Новая версия живёт в той же странице, а старая получает пометку: «иди дальше по ctid». Получается цепочка версий внутри страницы - HOT-chain.

Индекс по-прежнему указывает на самую первую (корневую) версию. Когда мы читаем строку через индекс, PostgreSQL приходит на корень цепочки и идёт по ctid до версии, видимой нашему снимку. Один лишний шаг по странице вместо записи в N индексов - выгодный обмен.

Проверить, что обновление было HOT, можно по счётчику:

SELECT n_tup_upd, n_tup_hot_upd

FROM pg_stat_all_tables WHERE relname = 'acc';

Если n_tup_hot_upd вырос вместе с n_tup_upd - индексы не тронуты. Подробный разбор условий и счётчиков - в hot-updates.

HOT хрупок. Достаточно изменить любую индексируемую колонку - и обновление перестаёт быть HOT, новая версия получает свои записи во всех индексах.

-- HOT: note в индексе, но мы его не трогаем

UPDATE acc SET balance = 300 WHERE id = 1;

-- НЕ HOT: note входит в acc_note_idx и меняется

UPDATE acc SET note = 'alice2' WHERE id = 1;

Второй UPDATE не может быть HOT, потому что новая запись в acc_note_idx обязана появиться - старый ключ 'alice' больше не ведёт к актуальной версии.

Отсюда практический вывод, к которому мы вернёмся в главе про проектирование индексов: чем больше колонок вы покрываете индексами, тем реже обновления остаются HOT и тем дороже каждая запись. Индекс на часто меняющуюся колонку - это плата не только за место, но и за потерю HOT.

Можно подумать: «у меня нет индекса на balance, значит UPDATE balance всегда HOT». Не всегда. Второе условие - помещается ли новая версия в ту же страницу - не зависит от индексов вовсе.

Если страница заполнена под завязку, новой версии просто негде разместиться рядом. PostgreSQL кладёт её в другую страницу, и тогда HOT невозможен по определению: цепочка не может пересекать границу страницы. Индексам приходится получить новую запись с ctid из другой страницы.

В PostgreSQL 16 для такого случая завели отдельный счётчик n_tup_newpage_upd - «обновление ушло в новую страницу». Если он растёт, а n_tup_hot_upd стоит, значит страницам не хватает места под обновления. Лечится это fillfactor - о нём следующий раздел.

По умолчанию PostgreSQL набивает страницу таблицы данными полностью - fillfactor = 100. Логично для таблицы, которую только читают: ни байта впустую. Но для таблицы с частыми UPDATE это означает, что почти любое обновление выталкивает новую версию в другую страницу - и HOT не работает.

fillfactor говорит: «заполняй страницу только на N процентов, а остаток придержи под будущие версии».

ALTER TABLE acc SET (fillfactor = 75);

-- новые страницы заполняются на 75%, 25% в резерве под HOT

Значение 75-90 - типичный выбор для часто обновляемых таблиц. Чем больше резерв, тем чаще обновления остаются HOT, но тем больше места таблица занимает на диске «вхолостую». Это компромисс, и настраивают его под конкретную нагрузку, измеряя hot_update_ratio.

SELECT relname,

       n_tup_hot_upd,

       round(100.0 * n_tup_hot_upd / nullif(n_tup_upd, 0), 1)

         AS hot_ratio_pct

FROM pg_stat_all_tables WHERE relname = 'acc';

Копнуть глубже: fillfactor не трогает существующие страницы. ALTER TABLE ... SET (fillfactor = ...) влияет только на страницы, которые PostgreSQL заполняет после изменения. Уже плотно набитые страницы останутся такими, пока их не перепишет VACUUM FULL или CLUSTER. Поэтому эффект от снижения fillfactor на живой таблице проявляется постепенно, по мере того как страницы перерабатываются.

HOT-цепочки не растут бесконечно. Если строку обновить десять раз подряд в одной странице, образуется цепочка из десяти версий, из которых актуальна одна, а девять - мусор. Места под новые версии скоро не останется.

Здесь включается второй механизм - внутристраничная очистка, или prune. Это лёгкая, локальная уборка: она затрагивает ровно одну страницу и не лезет в индексы. PostgreSQL запускает её оппортунистически - прямо во время чтения или обновления страницы, если видит, что та забита мёртвыми версиями.

Prune проходит по HOT-цепочкам страницы и выкидывает версии, которые уже не видны ни одному снимку. Освободившееся место возвращается в страницу под новые версии. При этом указатели (line pointers) перестраиваются: вместо длинной цепочки остаётся короткая, а ненужные указатели помечаются как мёртвые или переиспользуются.

Важное ограничение: prune убирает мусор внутри страницы, но не может тронуть индексы - для этого нужен полноценный VACUUM (глава 14). Поэтому указатель, на который ещё может ссылаться индекс, prune не удаляет, а превращает в redirect.

Вот тонкость, ради которой существует prune в его нынешнем виде. Индекс ссылается на корневую версию HOT-цепочки по её ctid, например (0,1). Если prune просто удалит корневую версию как мусор, индекс начнёт указывать в пустоту.

Чтобы этого не случилось, корневой указатель не удаляется, а превращается в redirect: line pointer с флагом LP_REDIRECT, который сам не ведёт к данным, а перенаправляет на следующий живой указатель в цепочке.

CREATE EXTENSION IF NOT EXISTS pageinspect;

SELECT lp, lp_flags, t_ctid

FROM heap_page_items(get_raw_page('acc', 0));

В выводе lp_flags = 2 (LP_REDIRECT) - это и есть перенаправляющий указатель. Индекс приходит на него, видит «не здесь, иди на указатель N» и идёт дальше по цепочке. Так физический мусор убран, место освобождено, а индекс по-прежнему находит актуальную версию, не зная, что внутри страницы всё переехало. Значения lp_flags подробно - в heap-pruning.

Сложим картину. Три механизма работают вместе, чтобы UPDATE не разорял индексы и страницы не пухли:

fillfactor управляет веткой «есть место в странице»: оставляя резерв, мы держим обновления в HOT-русле. Prune не даёт цепочкам переполнить страницу. А индексы остаются нетронутыми, пока мы не трогаем индексируемые колонки.

Чего этот тандем не умеет - убирать мусор, на который ссылаются индексы из других страниц, и продвигать горизонт заморозки. Это работа VACUUM, и ей посвящены следующие три главы.