sql - Postgres : one table with many columns or several tables with fewer columns?

Question

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

我有一张 table :

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 = Action 数

然后，如果你拆分它，你就是在试图计算这个:

成本 = gU1 + hU2 + xS1 + yS2

在哪里

U1 = 更新较小的表(成本较低)

U2 = 更新更大的表(成本更低)

S1 = 从较小的表中选择

S2 = 从更大的表中选择

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

所以如果 g >> h，将它们分解是值得的。特别是如果 x >> y 那么它真的很划算。

编辑:作为对评论的回应，我还要指出，如果数据库处于持续负载下且没有闲置状态，这些成本将变得更加重要。相反，如果服务器没有经历持续负载，它大部分时间都处于非事件状态，每秒只有 1 或 2 trx，并且长时间不活动(其中“长”=几秒)，那么，如果是我，我不会复杂化我的代码，因为性能优势不会显示为真正可衡量的东西。