四、存储、页与元组
本章讲清 PostgreSQL 数据在磁盘上的物理组织：页如何布局、堆元组如何存放、大字段如何压缩或线外存储，以及辅助文件与表空间的作用。它为第五章 MVCC提供物理基础：元组头参与可见性判定，页内旧版本与空闲空间决定清理和复用的成本。
知识结构
- TOAST（The Oversized-Attribute Storage Technique，超大属性存储技术）：根据字段类型、行大小与存储策略进行压缩或线外存储，其附属表是独立关系，不是主表的一个 fork。
- FSM（Free Space Map，空闲空间映射）：帮助插入寻找可复用空间。
- VM（Visibility Map，可见性映射）：为仅索引扫描和清理提供页级可见性信息。
此图针对普通堆表；分区父表、索引与其他对象的物理组织需分别判断。页大小通常为 8 KiB，以目标实例 SHOW block_size; 为准。
本章目录
学习目标
- 说清页（block）的结构：页头、行指针、元组、特殊空间
- 理解堆元组的物理布局与
ctid的含义 - 理解 TOAST 如何处理大字段、FSM/VM 的作用
- 了解表空间与物理文件（relfilenode、分段、fork）的组织
学习检查
| 观察方法 | 应能解释的问题 |
|---|---|
ctid 与 pageinspect 页检查 | 块号、行指针号和元组的位置是什么关系？为什么更新后的物理位置不能当作业务标识？ |
pg_relation_size 与 pg_total_relation_size | 主数据、辅助 fork、TOAST 与索引分别贡献多少空间？ |
pg_relation_filepath | 关系在当前实例中对应什么相对路径？为什么不能把文件名永久等同于对象标识？ |
按两篇正文在隔离库中观察页布局和空间组成，再进入多版本并发控制（Multi-Version Concurrency Control，MVCC）专题理解版本可见性。单看 xmin、xmax 或页内空洞，不能直接判定哪些版本可以回收。
依赖与前置
- 前置：三、架构与进程。
- 下一章：五、MVCC、Vacuum 与膨胀。
- 后续深入：八、索引原理与设计。