The one thing to understand first
A row on disk is not a tidy list of named fields — it is a packed byte string with a header, an optional NULL bitmap, and then the column values laid end to end with alignment padding wedged between them. Turning that byte string back into usable column values is called deforming, and PostgreSQL does it for nearly every tuple it touches. Once you see how deforming works, two surprising facts fall out: column order can change how many bytes a row occupies, and reading a late column can cost more than reading an early one.
What a heap tuple looks like
The on-disk layout is defined by HeapTupleHeaderData in src/include/access/htup_details.h:
- A 23-byte header (xmin, xmax, ctid, infomask flags…).
t_bits[] — the NULL bitmap, one bit per column, present only when the row actually contains a NULL (flagged by HEAP_HASNULL in t_infomask).t_hoff — the offset where user data begins, after the header and any NULL bitmap.- The column values themselves, each preceded by however many alignment padding bytes its type requires.
Deforming, one attribute at a time
The work happens in heap_deform_tuple() in src/backend/access/common/heaptuple.c. It walks the tuple left to right, and for each column consults pg_attribute: