Postgres：组合列的优点答案

【问题标题】：Postgres: Advantages of combining columnsPostgres：组合列的优点
【发布时间】：2017-01-01 08:41:41
【问题描述】：

背景：

我有以下大小的三列（共 8 个字节）：4（int）、2（small int）、2（small int）。

我正在对这三列（按照上面指定的顺序）创建一个多列（也称为复合）索引。我将执行两种类型的选择查询：

问题：Postgres 将这三列合并为一个 8 字节的 bigint 并在应用层处理分离有什么好处？

我想了解关于数据库查询和存储效率的观点。

【问题讨论】：

对于案例 #2，您会注意到读取性能有所提高，但是写入需要更长的时间，因为它需要更新 3 列而不是 1 列。索引本身实际上只是一个哈希集，它将占用 1 列现有索引大小的大约 3 倍。多列索引不会提高单列搜索的性能。您需要为#1 提供单列索引，为#2 提供多列索引。请记住，您拥有的索引越多，写入速度就越慢。
@KraangPrime：多列索引绝对可以加速单列条件 - 特别是如果它们条件适用于第一列。但即使在某些情况下使用尾随列
@a_horse_with_no_name - 抱歉，我应该澄清一下。如果它不是主索引，则它没有影响。如果您索引 (A, B, C)，并仅查询 (B) 或 (C) 之一，则根本不使用索引进行查找。对于使用索引的查找，必须使用所有部分或至少主要部分才能产生任何影响。见this explanation
@KraangPrime：Postgres 仍然能够将索引用于条件，例如B 列或 C 列 - 虽然效率不高。参见例如这里：thebuild.com/blog/2016/12/30/… 与它是否是主键无关。如果您在非 PK 列上创建索引并且具有显着减少行数的条件，则无需在条件中包含任何 PK 列。
@a_horse_with_no_name - 主 index 指的是多列索引中的第一列——不是primary key。这就是我这样说的原因:)

【解决方案1】：

我怀疑存储方面的任何合并收益都将很小，并且会被这样做的限制所抵消。是的，您可以合并，但不能对字段的子部分进行任何参照完整性检查。 IE。元组 A 可以与元组 B 相关，但 A 和 B 必须是表的整个字段的子集。这是1NF原子性要求的基础。

现在，您可以使用函数在字段内部查询以提取您需要的信息，如果您知道自己在做什么，您甚至可以索引这些函数的输出。但这会比其他方式使用更多的空间，并且您仍然会失去执行参照完整性的可能性。

一般来说，空间是一个问题，但不是在这个优化级别。除非您有非常特殊的需求，否则组合这些值会带来比解决的问题更多的问题。

【讨论】：