4장. Storage · Tuple · TOAST

3장이 MVCC의 논리였다면, 이 장은 그 논리가 디스크 위에 실제로 놓이는 모습입니다. 모든 것의 단위는 8KB 페이지 — 그 안에 튜플이 쌓이는 법, 큰 값이 밀려나는 법(TOAST)을 그림으로 봅니다.

4.1 8KB 페이지의 해부 — 양 끝에서 자라는 구조

PostgreSQL의 모든 heap·인덱스 파일은 8KB 고정 크기 페이지(block)로 구성됩니다. 테이블 파일은 1GB 단위 세그먼트로 쪼개지고요. 페이지 내부는 다섯 영역입니다: PageHeader(24B) → ItemId 배열 → Free Space → Tuples → Special. 재미있는 점은 ItemId는 앞에서, 튜플은 뒤에서 자라 가운데 빈 공간을 좁혀 간다는 것. INSERT가 반복될 때 무슨 일이 벌어지는지 봅시다.

4.2 튜플의 실제 크기 — 헤더 23B + 정렬(padding)의 비용

모든 튜플 앞에는 3장에서 본 23바이트 헤더(xmin·xmax·ctid·infomask…)가 붙고, 그 뒤에 사용자 데이터가 옵니다. 여기서 초보자가 자주 놓치는 비용이 alignment(정렬)입니다. bigint는 8바이트 경계, integer는 4바이트 경계에 놓여야 해서, 컬럼 순서가 나쁘면 빈틈(padding)이 생깁니다.

-- 나쁜 순서: smallint → bigint → smallint
CREATE TABLE bad  (a smallint, b bigint, c smallint);
-- 2B + (6B padding!) + 8B + 2B + (6B padding) = 24B

-- 좋은 순서: 큰 정렬 타입 먼저
CREATE TABLE good (b bigint, a smallint, c smallint);
-- 8B + 2B + 2B + (4B padding) = 16B  ← 행마다 8B 절약

4.3 fillfactor와 HOT Update — 일부러 비워두는 지혜

기본 fillfactor는 100 — 페이지를 꽉 채웁니다. 그런데 UPDATE가 잦은 테이블이라면? 새 버전 튜플이 같은 페이지에 들어갈 자리가 없어 다른 페이지로 가고, 그러면 인덱스에도 새 엔트리를 추가해야 합니다(Non-HOT). fillfactor를 80~90으로 낮춰 여유를 남기면, 새 버전이 같은 페이지에 들어가는 HOT(Heap-Only Tuple) update가 가능해집니다.

-- UPDATE가 잦은 테이블: 여유 공간을 미리 확보
ALTER TABLE orders SET (fillfactor = 80);
-- 대신 디스크 점유는 그만큼 늘어난다 (트레이드오프)

4.4 TOAST — 8KB에 1MB를 넣는 마법

규칙: 한 튜플은 한 페이지에 들어가야 한다. 그런데 50KB짜리 JSONB는요? 답이 TOAST(The Oversized-Attribute Storage Technique)입니다. 튜플이 약 2KB(TOAST_TUPLE_THRESHOLD)를 넘으면 큰 컬럼 값을 압축하고, 그래도 크면 별도의 숨겨진 테이블로 청크 단위 분할 저장합니다. 2KB의 근거는 "8KB 페이지에 최소 4개 튜플은 들어가게"입니다.

-- 전략 변경 (이후 UPDATE부터 적용)
ALTER TABLE articles ALTER COLUMN body SET STORAGE EXTERNAL;

-- PG14+: 더 빠른 lz4 압축으로
ALTER TABLE articles ALTER COLUMN body SET COMPRESSION lz4;

-- 내 테이블의 TOAST 테이블 찾기
SELECT relname, reltoastrelid::regclass
FROM pg_class WHERE relname = 'articles';
--  articles | pg_toast.pg_toast_16432

4.5 VM과 FSM — 테이블 옆의 두 조수

각 테이블 본체 파일 옆에는 보조 파일(fork)이 두 개 붙습니다: 24576_fsm, 24576_vm.

• Visibility Map(VM) — heap 페이지마다 2비트. all-visible(dead tuple 없음, 모두에게 보임)이면 Index-Only Scan이 heap을 건너뛸 수 있고, all-frozen이면 VACUUM이 그 페이지를 스킵합니다.
• Free Space Map(FSM) — 페이지별 남은 공간을 트리로 요약. INSERT·Non-HOT UPDATE가 "자리 있는 페이지"를 빨리 찾게 해줍니다.

-- Index-Only Scan이 진짜로 heap을 안 읽었는지 확인
EXPLAIN (ANALYZE, BUFFERS)
SELECT user_id FROM orders WHERE user_id = 42;
-- Index Only Scan using idx_orders_user ...
--   Heap Fetches: 0   ← 완벽 (VM 비트가 1)
--   Heap Fetches: 12  ← VACUUM 지연 신호. VACUUM 후 다시 측정

4.6 CTID — 물리 주소는 영원하지 않다

모든 튜플의 물리 주소는 (블록 번호, ItemId 번호) 쌍, 즉 CTID입니다. 인덱스 엔트리가 가리키는 것이 바로 이 값이죠. 단, CTID는 UPDATE·VACUUM FULL·CLUSTER로 바뀌는 불안정한 주소입니다. 애플리케이션이 저장해 두면 안 되고, 진단·복구 용도로만 씁니다. 영구 식별자는 bigserial·uuid 같은 논리 키로.

SELECT ctid, id, name FROM users LIMIT 3;
--  ctid  | id | name
-- -------+----+-------
--  (0,1) |  1 | Alice     ← 블록 0, ItemId 1
--  (0,2) |  2 | Bob
--  (1,1) |  4 | Dave      ← 블록 1로 넘어감

✍️ 이해도 체크