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