Длинные значения: TOAST

8.1 Строка не пересекает страницу

8.2 Порог и два приёма

8.3 Сжатие на месте

CREATE TABLE toast_demo (id int, big text);

INSERT INTO toast_demo VALUES (1, repeat('A', 5000));

SELECT pg_column_size(big) AS stored, octet_length(big) AS logical

FROM toast_demo;

--  stored | logical

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

--      69 |    5000

8.4 Вынос наружу

INSERT INTO toast_demo

SELECT 2, string_agg(md5(g::text), '') FROM generate_series(1, 200) g;

-- ~6400 несжимаемых байт

SELECT id, pg_column_size(big) AS stored, octet_length(big) AS logical

FROM toast_demo WHERE id = 2;

--  id | stored | logical

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

--   2 |   6400 |    6400

SELECT reltoastrelid::regclass FROM pg_class WHERE relname = 'toast_demo';

-- pg_toast.pg_toast_16566   (число - oid, у тебя своё)

8.5 Четыре стратегии хранения

SHOW default_toast_compression;   -- pglz (или lz4, если включён)

8.6 Подводный камень: длинное значение и btree

Уроки в sandbox

Резюме

• Строка не может пересекать границу страницы 8 КБ, поэтому длинные значения обрабатываются особо.
• При превышении порога (~2000 байт) PostgreSQL сначала сжимает длинные поля, потом выносит наружу.
• Сжимаемое значение остаётся в строке в сжатом виде; несжимаемое уходит в TOAST-таблицу чанками по ~1996 байт.
• У каждой таблицы с длинными колонками своя TOAST-таблица (reltoastrelid); значение собирается из чанков по требованию.
• Стратегии хранения: PLAIN, MAIN, EXTERNAL, EXTENDED (по умолчанию для длинных типов).
• Значение длиннее ~1/3 страницы нельзя положить в btree-индекс - ограничение btree, не хранения.

Контрольные вопросы

1. Какие два приёма и в каком порядке применяет TOAST к длинному значению?

   Показать ответ

   Сначала сжатие: длинные поля переменной длины сжимаются, и если строка после этого влезает под порог, значение остаётся в строке в сжатом виде. Если сжатия мало, применяется второй приём - вынос наружу: значение перемещается в отдельную TOAST-таблицу и нарезается на чанки примерно по 1996 байт, а в строке остаётся короткий указатель на него.

2. Как по pg_column_size и octet_length понять, что произошло со значением?

   Показать ответ

   octet_length - логическая длина значения, pg_column_size - его реальный размер на диске. Если pg_column_size заметно меньше octet_length - значение сжалось и, скорее всего, осталось в строке. Если они примерно равны и при этом велики - значение несжимаемо и вынесено в TOAST-таблицу без сжатия. Так по двум числам видно судьбу значения.

3. Зачем существует стратегия EXTERNAL, если EXTENDED умнее?

   Показать ответ

   EXTENDED сжимает значение перед выносом, EXTERNAL выносит без сжатия. EXTERNAL ставят осознанно, когда часто читают не всё значение целиком, а его куски - подстроки текста, срезы bytea. Несжатое значение можно прочитать частично, не распаковывая целиком, поэтому частичные чтения получаются быстрее. Это размен места (без сжатия значение крупнее) на скорость частичного доступа.

4. Почему нельзя просто построить btree-индекс по длинному текстовому полю?

   Показать ответ

   Потому что запись btree-индекса должна помещаться в страницу индекса, а значение длиннее примерно трети страницы туда не влезает. Ограничение именно у btree, и вынос значения в TOAST его не обходит. Для поиска по длинным значениям используют другие подходы: индекс по хешу или префиксу либо полнотекстовый индекс по разобранному представлению.

5. Почему короткий SELECT id не платит за длинное значение в той же строке?

   Показать ответ

   Потому что вынесенное в TOAST значение хранится отдельно, а в самой строке лежит только короткий указатель на него. Сервер собирает большое значение из чанков TOAST-таблицы лишь тогда, когда оно реально понадобилось в запросе. SELECT id длинную колонку не запрашивает, поэтому её чанки не читаются - запрос платит только за нужные колонки.