相关疑难解决方法(0)

根据PostgreSQL 的文档，VARCHAR,VARCHAR(n)和之间没有性能差异TEXT。

我应该为名称或地址列添加任意长度限制吗？

编辑：不是欺骗：

• 当所有值都是 36 个字符时，使用 char 和 varchar 进行索引查找会明显更快吗

我知道这种CHAR类型是过去的遗物，我不仅对性能感兴趣，而且对其他优缺点感兴趣，例如 Erwin 在他惊人的回答中所述。

我有一个旧模式（免责声明！），它使用基于哈希生成的 id 作为所有表的主键（有很多）。这种 id 的一个例子是：

922475bb-ad93-43ee-9487-d2671b886479

改变这种方法是不可能的，但是索引访问的性能很差。撇开这可能的无数原因不谈，我注意到有一件事似乎不太理想 - 尽管所有许多表中的所有 id 值的长度都正好是 36 个字符，但列类型是varchar(36)，而不是 char(36)。

将列类型更改为固定长度是否会char(36)提供任何显着的索引性能优势，除了每个索引页的条目数量增加很小等之外？

即在处理固定长度类型时 postgres 的执行速度是否比处理可变长度类型快得多？

请不要提及微小的存储节省 - 与对列进行更改所需的手术相比，这无关紧要。

我想从Postgres 文档中询问这个片段关于varchar(n)类型的含义：

短字符串（最多 126 个字节）的存储要求是 1 个字节加上实际字符串，其中包括字符情况下的空格填充。较长的字符串有 4 个字节的开销而不是 1 个字节。

假设我有一个varchar(255)字段。现在，以下声明：

• 如果该字段包含 10 个字节的字符串，则开销为 1 个字节。因此该字符串将使用 11 个字节。
• 如果该字段使用 140 个字节保存字符串，则开销为 4 个字节。因此该字符串将使用 144 个字节。

上面的那些说法是真的吗？这里有人理解文档相同的方式，我不过这里有人指出的开销总是4个字节在这里？