Postgres能否仅对复合主键部分列强制唯一以支持index-only scans

你的猜想是正确的：Postgres 不支持仅对复合主键的部分列强制实现唯一性，这是数据库主键设计的底层规则决定的，没有内置配置可以跳过这个限制。

你提供的建表语句对应的主键约束，实际效果是：

• 只会强制 id + yesno + extra 三列的整体组合唯一，完全无法实现你要求的「id 与 yesno 组合具备唯一性」的核心目标
• 只要你把 extra 列写进 primary key(...) 的列清单，Postgres 就一定会把 extra 纳入唯一性校验范围，哪怕你本意只是想让它进索引拿 index-only scans 的能力，也会出现同一个 id+yesno 组合下可以插入不同 extra 值的多条记录的情况，直接破坏你要的唯一规则。

你担心的「在 id+yesno 上单独建唯一索引会浪费存储」是可以完全避免的，根本不需要走重复建两个索引的老路：

• 直接把主键的列清单锚定在需要唯一的两列上，也就是 primary key (id, yesno)，天然满足两列组合唯一的要求
• 直接把 extra 列作为 INCLUDE 子句的附属列挂进这个主键的 B-tree 索引里，这部分列不参与主键的唯一性校验，但是会完整存在索引结构里，完全可以支撑 index-only scans 的特性要求
• 这种写法对应的实际建表语句参考：

create table foo (
  id integer,
  yesno boolean,
  extra text,
  primary key (id, yesno)
) include (extra);

• 这种方案的存储开销和你原本想的「把 extra 全放进主键列」的方案几乎没有差别，因为 INCLUDE 列是和主键主索引存在同一份物理结构里的，不会额外生成一套独立的索引树，完全不存在存储冗余的问题。

你之前考虑的"三列当主键+额外建id+yesno唯一索引"的方案才是真的会产生冗余存储的场景，只要换用INCLUDE的写法，完全可以同时满足唯一规则、index-only scan能力、零额外存储开销三个目标，根本不需要靠拆分主键部分列唯一性这种数据库不支持的逻辑来实现。

内容的提问来源于stack exchange，提问作者ccleve