小编dav*_*tgq的帖子

考虑以下示例：两个表foo和bar，每个表都有一个 jsonb 列。

• 对于foo，有一百万行 jsonb 的值是[{"a":123}]。

• 对于bar，有一百万行，其中 jsonb 的值是[{"very_long_key_not_premature_optimization_at_all":123}]

json key inbar比 in 长 46 个字符foo。的大小bar会比 4600 万字节大foo吗？

由于 PostgreSQL 没有 1 字节的tinyint，所以第二好的选择是smallint。然而，我从各种帖子中读到，它实际上可能会更慢，因为 CPU 已针对 32 位整数进行了优化，或者可能存在到 32 位整数的隐式转换。

除了这些原因之外，是否还有其他我不知道的不使用小于 32 位整数的原因？

与相同数据类型的普通列相比，数组的额外开销是多少？换句话说，如果一个数组几乎总是有一个值，那么使用数组而不是普通列会“浪费”多少空间？

我决定使用可为空字段或 jsonb 来存储用户配置文件。最初，这将用于联系人：email和phone。我预计稍后可能会添加其他列，例如mobile和website。此外，可能还有其他不相关的字段，例如设置/首选项、保存的搜索等。

我已经决定我不想为此使用任何形式的键值存储（或任何涉及多对多关系的模式），除非有非常好的理由。

jsonb 的优点：

• 如有必要，可以为每个“列”存储多个值
• 添加新字段只需要 JS 编码和文档

jsonb 的缺点：

• 将“列”名称存储为每个“行”的字符串的开销
• Wonky 执行比较查询（我认为我的使用场景不适用）
• 不得不期待意外

还有什么要添加到这个优点/缺点列表中的吗？尽管我只想使用可为空的列，但我认为忽略 jsonb 是一种疏忽 - 这似乎是一个令人信服的选择。

例如：

• timestamp(tz) 到 int8
• date 到 int4
• json 到 text

原始数据不变，唯一的区别是数据的处理方式。因此，应该可以干净且即时地来回更改。

1. 我如何检查是否确实如此？

2. 如果不是这种情况（表格被重写），我如何在不重写的情况下做到这一点？