PostgreSQL中PK与CTID并行导出数据的性能差异及选型疑问

一、死元组导致CTID导出变慢的原因 #

是的，核心原因就是更新产生的死元组推高了relpages（表的物理块总数），进而增加了CTID分片导出的开销：

• CTID是PostgreSQL行的物理位置标识，格式为(块号, 块内偏移)，按CTID范围分片本质是遍历表的物理数据块。当表中存在大量死元组（比如50%占比），这些死元组会长期占用物理块空间（除非执行VACUUM FULL彻底回收，普通VACUUM仅标记空间可复用），导致表的物理块总数relpages大幅增加。
• 此时按CTID分片导出时，每个任务需要扫描更多的物理块，且大量块中包含无效死元组，需要额外判断过滤，直接增加了IO读取量和CPU处理开销。
• 而按PK范围导出时，查询依赖主键的B-tree索引，索引仅指向活元组的最新物理位置，不会遍历那些堆满死元组的无效块，因此能跳过大量无用数据，效率更高。

二、多数场景偏好CTID的原因 #

尽管在死元组较多时CTID表现不佳，但它仍是并行导出的首选方案，核心在于通用性和实现成本：

• 通用性极强：所有PostgreSQL表默认都有CTID，无需依赖业务主键的存在或结构——比如无主键表、复合主键表、UUID这类非连续主键的表，用CTID可以轻松实现均匀分片；而PK分片需要主键是连续、分布均匀的类型（如自增整数），否则容易出现分片数据量不均的问题。
• 无额外索引依赖：如果表的主键索引存在碎片、或者根本没有主键，CTID导出无需走索引，直接扫描物理块；在表干净（死元组少）的场景下，效率和PK方式相当，甚至因为少了索引跳转的开销略快。
• 实现逻辑简单：无需提前分析主键的分布范围、是否存在空洞，直接通过pg_class系统表的relpages字段就能计算出均匀的CTID分片范围，代码逻辑简洁，不容易出错。
• 快照一致性下的稳定性：在REPEATABLE READ事务快照中，行的物理位置（CTID）是固定的（快照期间不会有VACUUM FULL移动行数据），分片逻辑不会因为数据的逻辑变化（如主键更新）出现偏差。

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