PostgreSQL默认分区无法被ATTACH,只能通过CREATE TABLE ... PARTITION OF ... DEFAULT一次性定义;其本质是约束匹配终点而非可挂载容器,替换需drop+recreate且不支持原子操作。

默认分区无法直接 attach 分区表
PostgreSQL 的 DEFAULT 分区是兜底容器,它不参与范围/列表约束的显式匹配,因此不能像普通分区那样被 ATTACH PARTITION。一旦你执行 ALTER TABLE ... ATTACH PARTITION ... DEFAULT,会立刻报错:ERROR: cannot attach a partition to a default partition。
常见误操作场景:想把一个已有数据的表“转成”默认分区,或试图用 ATTACH 把历史归档表塞进默认分区里 —— 这在语义上不成立,因为 DEFAULT 分区本身就是一个逻辑终点,不是可扩展的挂载点。
-
DEFAULT分区只能通过CREATE TABLE ... PARTITION OF ... DEFAULT一次性定义 - 已存在的独立表无法通过
ATTACH变成默认分区;必须先清空或重定向数据,再重建为DEFAULT分区 - 若需动态扩展默认行为(比如按时间归档+兜底),应考虑用触发器或应用层路由,而非依赖
DEFAULT分区承载新逻辑
attach 操作前必须满足约束兼容性
即使目标不是 DEFAULT 分区,ATTACH PARTITION 也会严格校验被挂载表的约束是否与父表分区键完全匹配。典型失败原因不是语法错,而是隐含的约束冲突。
例如父表按 LIST (status) 分区,而你要 attach 的表虽然有 status 字段,但缺少 CHECK (status IN ('active', 'inactive')),或者约束名重复、表达式写法不一致(如用 status = 'active' 而非 status IN ('active')),都会导致 ERROR: partition constraint is violated by some row 或更隐蔽的 ERROR: no partition of relation "xxx" found for row。
- 用
\d+ parent_table查看父表各分区的约束定义,逐字比对 - 被 attach 表必须是空的,或提前运行
ANALYZE确保统计信息准确,否则约束检查可能误判 - 若表含继承关系或触发器,需先
DETACH或禁用,否则 attach 会拒绝
默认分区影响查询计划与数据分布
PostgreSQL 查询优化器会把 DEFAULT 分区当作“最后尝试”的分支,这在多条件查询中容易引发意料外的执行路径。比如父表按 RANGE (created_at) 分区,并设了一个 DEFAULT 分区收容未来日期或 NULL 值;当查询条件含 WHERE created_at > '2030-01-01',优化器可能跳过所有范围分区,直接扫描 DEFAULT 分区 —— 即使该分区实际为空,也可能拖慢计划生成或引入 seq scan。
- 默认分区的数据不会自动“溢出”到其他分区;插入时只按约束判断,不回退重试
- 若业务上能明确划分边界(如用
MAXVALUE替代DEFAULT),优先不用DEFAULT,避免优化器路径模糊 - 监控
pg_stat_all_tables中默认分区的n_tup_ins和n_tup_hot_upd,异常增长往往意味着上游写入逻辑未对齐分区策略
替换默认分区需 drop + recreate,无法 in-place 更新
没有 ALTER TABLE ... REPLACE DEFAULT PARTITION 这种语法。如果需要变更默认分区的结构(比如加字段、改类型、换存储参数),唯一安全方式是:新建一个兼容约束的新表,把原 DEFAULT 分区数据搬过去,然后 DETACH 旧分区并 DROP,最后 CREATE TABLE ... PARTITION OF ... DEFAULT 挂上新表。
这个过程不可原子化,且期间默认分区处于缺失状态 —— 所有本该落入其中的 INSERT 将报错 no partition of relation "xxx" found for row。生产环境务必安排维护窗口,并提前在应用层做降级处理(如暂存消息、重试队列)。
- 搬数据时用
INSERT INTO new_default SELECT * FROM old_default,不要省略字段列表,防止顺序错位 - 新表的
CONSTRAINT必须显式声明为NOT VALID再 attach,否则全表扫描验证会阻塞操作 - 若原默认分区很大,考虑分批迁移 + 触发器拦截写入,而不是锁表等待
默认分区不是“灵活容器”,而是带硬约束的终点;attach 不是文件链接,而是约束契约的现场验签。这两点不厘清,后续的分区膨胀、查询抖动、维护中断都只是时间问题。









