磁盘空间不降反升是因为TOAST表不会自动回收旧块：更新大字段时旧TOAST块仍保留，仅主表更新指针，需VACUUM FULL、pg_repack或VERBOSE VACUUM配合清理。
更新大文本字段时，为什么磁盘空间不降反升？
直接原因：TOAST 表不会自动回收旧块。PostgreSQL 更新 TEXT、JSONB 或 BYTEA 字段时，即使新值比旧值小很多，旧的 TOAST 块仍保留在 TOAST 表中，直到 VACUUM 清理。主表里只写入新指针，旧 TOAST 数据“悬空”但未释放。
典型现象：pg_total_relation_size('my_table') 持续增长，SELECT pg_size_pretty(pg_total_relation_size('pg_toast.pg_toast_12345')) 明显大于主表本身。
- VACUUM 不会立即清理 TOAST，需配合
FREEZE或等待事务 ID 回卷点 - UPDATE 触发新 TOAST 块写入，但旧块标记为“dead”，仍占磁盘
- 如果频繁更新同一行的大字段（如日志追加、JSON patch），TOAST 表碎片会快速堆积
如何让 UPDATE 真正复用空间？关键看 storage 策略
PostgreSQL 对 TOAST 列支持四种 STORAGE 模式，直接影响更新时的空间行为：
-
EXTENDED（默认）：先压缩，压缩失败或仍超 2KB 则分块存 TOAST。更新时倾向新建块，旧块留待 VACUUM -
MAIN：尝试压缩并尽量留在主行内；若压缩后 ≤2KB，则更新可能复用原位置，避免 TOAST 写入 -
EXTERNAL：强制分块、不压缩；更新必然产生新块，适合已知不可压缩的二进制流 -
PLAIN：禁用压缩 + 禁用分块；超长值直接报错ERROR: value too long for type xxx，不触发 TOAST
实操建议：对高频更新且内容常变小的字段（如状态描述、摘要），可显式设为 MAIN：
ALTER TABLE logs ALTER COLUMN summary SET STORAGE MAIN;
注意：设为 MAIN 后，若某次更新值压缩失败且 >2KB，仍会 fallback 到 TOAST，但概率降低。
哪些操作能真正释放 TOAST 空间？
VACUUM 本身不保证清理 TOAST —— 它只清理主表 dead tuple 和关联的 dead TOAST 行，前提是这些 TOAST 行没有被任何活跃事务引用。真正有效的释放路径有三条：
- 执行
VACUUM FULL my_table：重写整个表及关联 TOAST 表，彻底丢弃所有 dead 块（但会锁表） - 周期性运行
VACUUM (VERBOSE, ANALYZE) my_table，并确认输出含removed N row versions in pg_toast table - 对冷数据分区，用
CLUSTER或pg_repack在线重建（不锁写），同时整理 TOAST 表
特别注意：pg_repack 默认不处理 TOAST 表，需加 --no-order 或显式指定 --include-toasts（v1.5+）。
怎么快速判断当前字段是否在走 TOAST？
别只看类型声明 —— TEXT 不一定触发 TOAST，VARCHAR(10) 超长也可能触发。验证方法：
- 查系统目录：
SELECT column_name, storage FROM pg_attrdef a JOIN pg_attribute b ON a.adnum = b.attnum WHERE b.attrelid = 'my_table'::regclass; - 看实际存储：插入一个明显 >2KB 的值（如
repeat('x', 3000)），再查pg_toast目录：SELECT relname FROM pg_class WHERE relname LIKE 'pg_toast%12345';（12345 是主表 OID） - 监控写放大：开启
log_statement = 'mod'+log_min_duration_statement = 0，观察 UPDATE 是否伴随大量 TOAST 表的 INSERT
最容易被忽略的一点：TOAST 表的膨胀是静默的。它不体现在 pg_stat_all_tables 的 n_dead_tup 里，而藏在 pg_toast 下对应子表的统计中 —— 查 pgstattuple 扩展里的 pg_toast.pg_toast_12345 才能看到真实碎片率。
