Postgres 9.x 中 CHECK 约束的成本是多少？

Question

我有一个有 60 列的表。其中 20 个是“NotEmpty”，6 个是“NotNull”。

我有空值和 Null 值（在我的情况下总是意味着“没有数据”）。我想将列与一种类型的约束统一起来。

我读过空值很便宜（以字节大小计）。那么也许使用 NotEmpty 约束？但也许 NotNull 约束表现更好？coalesce()或者也许在检索数据时同时拥有值和使用会更好？

Postgres 9.x 中的约束CHECK成本是多少？你的经历怎么样？有什么基准吗？INSERTUPDATE

Answer 1

有些人试图避免NULL价值观，声称逻辑会令人困惑。

我不是他们中的一员。NULL值对于没有数据的列来说就很好。它们无疑是存储“空”列的最便宜的方式 - 对于磁盘空间和性能（主要影响是较小的表和索引）：

• 在 PostgreSQL 中不使用 NULL 是否仍然在标头中使用 NULL 位图？
• 在 postgresql 中的列上设置“NOT NULL”是否会提高性能？
• 可为 null 的列会占用 PostgreSQL 中的额外空间吗？

一旦理解了价值观的本质NULL，就没有理由回避它们。Postgres 提供了多种处理 NULL 的函数。colaesce(), nullif(), concat(),concat_ws() , ...

一般来说，就性能而言，NOT NULL 约束胜过CHECK 约束，并且两者都胜过日志射击触发。但即使是简单的触发器也很便宜。约束的成本NOT NULL几乎为零。此外，所有这些仅影响写入操作，但在大多数应用程序中读取操作占主导地位。

因此，对性能最相关的影响（除了次优索引和查询之外）是表和索引的大小，或者更重要的是每个数据页的元组数量。对于大多数用例来说，较大的元组会导致性能下降。为满足查询而必须读取的数据页数量相应增加。可用高速缓冲存储器较早饱和。

我还没有准备好基准测试，但最好还是针对您的特定环境进行测试。这些只是简单的经验法则。现实要复杂得多。