Файл таблицы и форки отношения

Таблица в PostgreSQL хранится не одним файлом, а набором параллельных файлов - форков (forks). Главный форк держит строки, остальные - служебные карты, которые ускоряют работу. Все они лежат рядом в подкаталоге базы и относятся к одной таблице. Полный разбор - в relfilenode-forks.

Зачем разносить по файлам? Чтобы служебные карты можно было читать и обновлять, не трогая основной массив данных. Карта свободного места крошечная по сравнению с таблицей, и держать её отдельным маленьким файлом дешевле, чем вплетать в данные.

Путь к главному файлу таблицы возвращает pg_relation_filepath:

SELECT pg_relation_filepath('flights');

-- base/16384/16503

Читается так: base/ - каталог обычных баз, 16384 - OID базы (совпадает со строкой lab из pg_database), 16503 - имя файла таблицы. Это имя называют relfilenode.

Числа на твоей установке будут другими: идентификаторы выдаются по мере создания объектов. Важна структура пути, а не конкретные цифры.

У отношения может быть до четырёх форков. Различают их по суффиксу имени файла:

Главный форк есть всегда. Карта свободного места (_fsm) помогает вставке быстро находить страницу с местом - подробно в free-space-map. Карта видимости (_vm) отмечает страницы, где всё видимо всем, и ускоряет чтение и очистку - о ней visibility-map. Форк _init нужен только нежурналируемым (UNLOGGED) таблицам как эталон для сброса после сбоя.

Сразу после CREATE TABLE на диске только главный форк. Служебные карты создаются позже - когда в них появляется смысл. Карту видимости, например, заполняет VACUUM. Это легко увидеть на размере форков:

CREATE TABLE forklab (id int, note text);

INSERT INTO forklab SELECT g, 'row'||g FROM generate_series(1, 300) g;

SELECT pg_relation_size('forklab', 'vm') AS vm_before;   -- 0: карты видимости ещё нет

VACUUM forklab;

SELECT pg_relation_size('forklab', 'vm') AS vm_after;    -- 8192: появился форк _vm

До VACUUM форк _vm имеет нулевой размер - его попросту нет. После - это 8192 байта: одна страница карты на маленькую таблицу. Так проявляется ленивость: PostgreSQL не заводит структуру, пока она не понадобилась.

У отношения два числа: OID (внутренний идентификатор в системном каталоге) и relfilenode (имя файла на диске). Поначалу они равны. Но команды, переписывающие таблицу целиком, создают новый файл с новым relfilenode, а OID оставляют прежним.

SELECT oid, relfilenode, oid = relfilenode AS same

FROM pg_class WHERE relname = 'forklab';

-- oid=16583, relfilenode=16583, same=t

VACUUM FULL forklab;          -- переписывает таблицу в новый файл

SELECT oid, relfilenode, oid = relfilenode AS same

FROM pg_class WHERE relname = 'forklab';

-- oid=16583, relfilenode=16588, same=f

После VACUUM FULL OID тот же, а relfilenode сменился. То же делают TRUNCATE, CLUSTER и ALTER TABLE, меняющий тип колонки. Поэтому в коде, который должен пережить перезапись таблицы, ссылаются на OID, а pg_relation_filepath всегда показывает актуальный relfilenode.

Один форк не растёт одним бесконечным файлом. Как только главный форк переваливает за 1 ГБ, PostgreSQL продолжает в файле relfilenode.1, потом relfilenode.2 и так далее. Это страховка от старых файловых систем с лимитом на размер файла и удобство для операций копирования.

На практике это значит: большая таблица на диске - это пачка файлов 16503, 16503.1, 16503.2, а не один гигантский. Логически - одна таблица, физически - набор сегментов по гигабайту.

Соблазнительно записать relfilenode таблицы и потом обращаться к файлу напрямую - например, в скрипте мониторинга. Не делай так. Любая перезапись таблицы (VACUUM FULL, TRUNCATE, смена типа колонки) даст новый relfilenode, и твоя ссылка станет указывать на удалённый или чужой файл.

Стабилен только OID. Если нужен путь, спрашивай его заново через pg_relation_filepath - он переведёт OID в актуальное имя файла. Имя файла - это снимок на момент запроса, а не вечный адрес.