Версия строки: заголовок кортежа

Строка в heap хранится как кортеж: служебный заголовок, за ним пользовательские данные. Заголовок занимает 23 байта и выравнивается до 24. В этих байтах - транзакционные штампы, ссылка на следующую версию и флаги. Подробный справочник полей - в tuple-header.

24 байта на каждую строку - это накладной расход многоверсионности. Маленькая строка из одного int (4 байта данных) на диске займёт под 30 байт: заголовок весит больше самих данных. На широких строках эти 24 байта незаметны, на узких - чувствительны.

Прочитать заголовки всех строк на странице можно так:

SELECT lp, t_xmin, t_xmax, t_ctid, t_infomask, t_hoff

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

Что в каждом поле:

t_xmin и t_xmax определяют время жизни версии. xmin - кто её создал, xmax - кто пометил устаревшей. У живой версии xmax = 0.

Эти же поля доступны как системные колонки прямо в выдаче таблицы, без pageinspect:

SELECT xmin, xmax, ctid, * FROM tup;

--  xmin | xmax | ctid  | id | note

-- ------+------+-------+----+------

--   797 |    0 | (0,3) |  1 | v3

По паре xmin/xmax транзакция решает, видеть ей версию или нет. Это и есть фундамент видимости, и ему посвящена отдельная заметка - xmin-xmax. Здесь важно одно: видимость не хранится флагом, а вычисляется из этих чисел.

Самое интересное поле - t_ctid. Обычно оно указывает на саму строку. Но после UPDATE старая версия начинает указывать на новую, и так получается цепочка. Соберём её руками: вставим строку и дважды обновим.

CREATE TABLE tup (id int, note text);

INSERT INTO tup VALUES (1, 'v1');

UPDATE tup SET note = 'v2' WHERE id = 1;

UPDATE tup SET note = 'v3' WHERE id = 1;

SELECT lp, t_xmin, t_xmax, t_ctid

FROM heap_page_items(get_raw_page('tup', 0)) ORDER BY lp;

--  lp | t_xmin | t_xmax | t_ctid

-- ----+--------+--------+--------

--   1 |    795 |    796 | (0,2)    <- v1: устарела (xmax=796), ведёт на (0,2)

--   2 |    796 |    797 | (0,3)    <- v2: устарела (xmax=797), ведёт на (0,3)

--   3 |    797 |      0 | (0,3)    <- v3: жива (xmax=0), ведёт на себя

Смотри, как сходятся числа: xmax каждой версии равен xmin следующей - это одна и та же транзакция, которая старую версию закрыла, а новую открыла. А t_ctid ведёт от версии к версии: (0,1) → (0,2) → (0,3). Конкретные номера транзакций у тебя будут другими, но связь та же. Сам SELECT * FROM tup показывает только живую версию (0,3) - остальные ждут, пока их уберёт vacuum.

Указатели строк, на которые ссылается ctid, мы разбирали в line-pointers: ctid - это пара «страница, номер указателя».

t_hoff - смещение от начала кортежа до первого пользовательского байта. Во всех строках выше оно равно 24: заголовок без дополнений.

Но если в строке есть NULL, после заголовка добавляется битовая карта NULL - по биту на колонку, отмечающему, какие из них пусты. Тогда t_hoff вырастает. Хитрость: сам NULL в данных места не занимает, его наличие отмечено битом в карте. Поэтому таблица, где много пустых колонок, на диске бывает компактнее, чем кажется по числу колонок.

Где именно лягут колонки за заголовком, определяет их выравнивание - этому посвящена следующая глава, column-alignment.

Поле t_infomask - набор битовых флагов. Часть из них описывает саму строку: есть ли NULL, есть ли поля переменной длины, является ли xmax блокировкой, а не удалением. Другая часть - подсказки фиксации (hint bits): закэшированный ответ на вопрос «а транзакция xmin/xmax точно зафиксировалась?».

SELECT t_infomask::bit(16) FROM heap_page_items(get_raw_page('tup', 0));

Подсказки ставит первый, кто прочитал строку после завершения её транзакции, чтобы следующим не лезть за статусом в clog. Это тонкий и неожиданный механизм - почему обычный SELECT может вызвать запись, - и ему посвящена отдельная заметка clog-hint-bits и глава в части про MVCC.

Увидев xmax, отличный от нуля, легко решить «строка удалена». Не всегда. xmax ставится не только при удалении или обновлении, но и когда строку просто блокируют: SELECT ... FOR UPDATE или вставка дочерней строки с внешним ключом.

-- у строк flights xmax заполнен, но сами строки живы:

-- их «придержала» вставка в tickets по внешнему ключу

SELECT xmin, xmax FROM flights LIMIT 1;

Такой xmax помечен флагом «только блокировка» в infomask, и правило видимости его игнорирует: строка остаётся живой. Поэтому ненулевой xmax сам по себе ещё не значит, что версия мертва - надо смотреть флаги. Мы вернёмся к этому в части про MVCC.