Postgres：一张多列的表还是几张少列的表？

Question

我的问题与 Postgres 的工作原理有关：

我有一张桌子：

CREATE TABLE A (
   id SERIAL,  
   name VARCHAR(32),
   type VARCHAR(32) NOT NULL, 
   priority SMALLINT NOT NULL,
   x SMALLINT NOT NULL,
   y SMALLINT NOT NULL,
   start timestamp with time zone,
   end timestamp with time zone,
   state Astate NOT NULL,
   other_table_id1 bigint REFERENCES W,
   other_table_id2 bigint NOT NULL REFERENCES S,
   PRIMARY KEY(id)
); 

在 other_table_id1、state 和 other_table_id2 上附加索引。

该表非常大，并且在列上看到了很多更新：other_table_id1、state。开始和结束列的一些更新，但其余的都是不可变的。（Astate 是列状态的枚举类型。）

我想知道将两个最常更新的列拆分到一个单独的表中是否有意义。我希望获得的是性能，因为当我只是查找该信息时，或者减少更新的权重，因为（也许？）读取和写入较短的行成本较低。但是，当（偶尔）需要一次性获得特定项目的所有数据时，我需要将其与连接成本进行权衡。

有一次，我的印象是每一列都是单独存储的。但是后来，当我在某处读到减少表格一侧列的宽度确实会对使用另一列查找数据时的性能产生积极影响时，我修改了我的想法（因为该行存储在一起，因此总行长度将更短）。所以我现在的印象是一行的所有数据都物理存储在磁盘上；所以提议的表格拆分听起来会很有帮助。当我当前写入 4 个字节来更新状态时，我是否相信我正在重写实际上从未改变的 64 个字节的文本（名称、类型）？

我对表“规范化”不是很熟悉，也不熟悉 Postgres 的内部结构，所以我正在寻找建议和 esp 最佳实践来估计权衡，而不必先做工作，然后确定这项工作是否值得. 这种变化需要相当多的努力来重写已经高度优化的查询，所以我宁愿深入了解我可以期待什么结果。谢谢，M。

Answer 1

更新较大的行是有一定成本的。

一个公式可以帮助解决这个问题。如果不拆分，您的成本为

成本 = xU + yS

在哪里：

U = 整行的更新（表未拆分）

S = 选择的成本

x,y = 动作计数

然后，如果你把它分开，你就会试图弄清楚：

成本 = gU1 + hU2 + xS1 + yS2

在哪里

U1 = 更新较小的表（成本较低）

U2 = 更新较大的表（成本较低）

S1 = 从较小的表中选择

S2 = 从更大的表中选择

g,h,x,y = 单个操作发生的频率

因此，如果 g >> h，则将它们分解是值得的。特别是如果 x >> y 那么它确实值得。

编辑：为了回应评论，我还想指出，如果数据库处于持续负载、没有不活动状态，这些成本就会变得更加重要。相反，如果服务器没有经历持续负载，它大多处于不活动状态，每秒仅 1 或 2 trx，并且长时间不活动（其中“长”=几秒），那么，如果是我，我不会复杂化我的代码，因为性能优势不会出现为真正可衡量的东西。