PostgreSQL declarative partitioning 的默认分区与 attach 操作

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 不是文件链接，而是约束契约的现场验签。这两点不厘清，后续的分区膨胀、查询抖动、维护中断都只是时间问题。