作为常年和PostgreSQL打交道的开发者，我可以明确告诉你：非常建议你执行ALTER TABLE t ALTER COLUMN c SET STORAGE PLAIN，原因主要有这几点：

• 强制规避TOAST机制的潜在影响
  虽然你的SHA1校验和只有20字节，远小于PostgreSQL TOAST机制的触发阈值（默认是页大小的1/4，也就是~2KB），默认情况下数据库不会对这么小的bytea字段做压缩或外置存储。但显式设置STORAGE PLAIN相当于给这个字段加了个“保险”——哪怕未来有人修改了toast_tuple_target这类系统参数，或者对表结构做了其他调整，都能确保主键列始终存储在主表的元组中，不会被意外触发TOAST处理。

• 消除额外的IO与计算开销
  主键和外键是查询、关联操作的核心依赖字段，必须保证极致的访问速度。如果字段被TOAST处理（哪怕只是理论上的可能性），数据库在读取时需要额外去TOAST表中获取数据，甚至还要做解压计算——这会直接拖慢JOIN、WHERE条件过滤、索引查找的性能。设置PLAIN存储后，20字节的校验和会直接存在主表页内，数据库可以一次性读取，完全没有额外开销。

• 优化索引访问效率
  主键默认会创建B-tree索引，索引中存储的是主键列的实际值（或指针）。如果字段是PLAIN存储，索引条目就是直接的20字节数据，查找时匹配速度极快；要是字段被TOAST处理，索引里存的会是指向TOAST数据的指针，查找到索引后还得再去TOAST表取实际值，多了一次IO操作。显式设置PLAIN能确保索引里存储的是真实的校验和值，让索引查询的效率最大化。

• 规整元组结构，提升内存利用率
  虽然你的bytea是固定20字节，但PostgreSQL的bytea本质是可变长度类型。设置STORAGE PLAIN后，数据库会把这个字段当作固定长度数据来处理（实际存储上也是固定的），让表的元组结构更规整，有助于数据库的缓存管理和内存分配，减少不必要的内存开销。

总的来说，这是一种防御性的性能优化——哪怕默认状态下不会有问题，显式设置STORAGE PLAIN能确保你的主键/外键列始终处于最优的存储状态，长期稳定地保障查询和关联性能。

内容的提问来源于stack exchange，提问作者A. Klimov