PostgreSQL TOAST列存储策略疑问：四类存储类型设置相关问题

嘿，我太懂你查资料卡壳的感觉了——PostgreSQL的TOAST机制细节真的多，光看文档里的定义，确实容易摸不清这四种存储策略到底怎么用、差异在哪。我来给你拆解得明明白白：

四种存储策略的核心行为差异 #

• PLAIN：完全禁用TOAST功能。如果你的列数据大小超过了数据库页面的可用空间（默认是8KB），插入或更新操作会直接报错。适合你能100%确定数据永远不会超标的小字段，比如短字符串、固定长度的数值，或者就是不想让数据被TOAST处理的场景。
• MAIN：这是大多数列的默认策略（除了不可压缩的类型比如bytea）。它会先尝试把数据压缩后塞进主表的页面里，只有当压缩后还是装不下的时候，才会把超出的部分放到单独的TOAST表中。这种策略平衡了存储空间和访问效率，既靠压缩省空间，又尽量保证常用数据存在主表里，减少额外的IO。
• EXTENDED：和MAIN逻辑类似，但优先级反过来——它会优先把压缩后的数据放到TOAST表，而不是硬塞主表。如果数据压缩后仍然很大，还会把数据分割成多个块存储。适合大文本、大JSON这类占用空间大的字段，优先保证主表页面不会被大数据占满，提升主表的整体查询效率。
• EXTERNAL：不做任何压缩，直接把超出主表页面的部分放到TOAST表。适合两种场景：一是数据本身已经被压缩过（比如你自己用gzip压缩后存在bytea里的文件），再压缩只会浪费CPU；二是你需要直接读取原始数据，不想额外解压的情况。

实际场景选择示例 #

举个例子：如果你的表有一个bytea列存用户上传的PDF文件，这些PDF本身已经是压缩格式的，那设置ALTER TABLE your_table ALTER COLUMN pdf_col SET STORAGE EXTERNAL就非常合适，避免PostgreSQL做无用功。而如果是存储长篇博客内容的text列，EXTENDED或者MAIN会更划算，能有效节省存储空间。

额外小提示 #

要注意的是，这些策略只对支持TOAST的类型生效，像integer这类固定大小的小类型，设置这些策略根本没用。你可以用这条SQL查看哪些类型支持TOAST：

SELECT typname, typstorage FROM pg_type WHERE typstorage != 'p';

这里typstorage字段的p对应PLAIN，m对应MAIN，e对应EXTENDED，x对应EXTERNAL。

内容的提问来源于stack exchange，提问作者Francis Bartkowiak