不能。detach后分区数据逻辑上从原表移除，select不再扫描，但物理文件仍在磁盘；detached分区变为独立表可单独查询，而error: relation "xxx" does not exist通常因误删该表或attach表名错误导致。
detach 之后表还能查吗？
不能。执行 ALTER TABLE ... DETACH PARTITION 后，该分区数据立即从原表逻辑上移除，后续 SELECT 不会扫描它，也不会报错——就像它从来没存在过。但物理文件还在磁盘上，没被删，这是零停机的前提。
常见错误现象：ERROR: relation "xxx" does not exist —— 这不是 detach 导致的，而是你误删了 detached 分区对应的表（比如用 DROP TABLE），或者 attach 时目标表名写错了。
- detach 是元数据操作，毫秒级完成，不影响主表其他分区的读写
- detached 分区会变成一张独立的、普通命名的表（如
mytable_1_prt_2），可单独查询、备份、压缩 - PostgreSQL 11+ 支持
DETACH PARTITION CONCURRENTLY，但仅限于某些场景，实际中不如手动加ACCESS EXCLUSIVE锁来得可控
attach 前必须做哪些校验？
不是把表丢进去就完事。PostgreSQL 要求 attached 表的结构、约束、索引、甚至统计信息都和目标分区表严格一致，否则直接拒绝。
使用场景：归档后想把旧分区重新挂回线上表（比如查历史数据），或跨库迁移归档分区回来。
- 字段顺序、类型、NOT NULL 属性必须完全相同；
SELECT * FROM结果列序不一致就会失败 - 检查约束（
CHECK）必须存在且表达式字面量一致，哪怕只是空格差异也会报cannot attach partition - 如果原表有主键或唯一索引，detached 表也得有同名、同列、同顺序的索引，否则
ATTACH报错 - 建议用
\d+对比两张表的 DDL，别只看\d—— 统计信息和存储参数也可能影响
为什么 detach/attach 后查询变慢了？
因为分区键统计信息丢失。detach 会清掉原表对该分区的统计，attach 后 PostgreSQL 不会自动继承 detached 表的 pg_statistic，优化器可能选错执行计划。
性能影响明显出现在大分区（>100GB）或高并发查询场景，尤其当新 attach 的分区被频繁 JOIN 或 FILTER 时。
- attach 完立即执行
ANALYZE目标表（不是 detached 表），触发全表统计收集 - 若等不及全表 analyze，可用
ANALYZE mytable (partition_col)只分析分区键列 - 避免在业务高峰 attach 大分区，即使操作快，analyze 阶段可能锁表并拖慢查询
路径和权限容易被忽略的点
detached 表默认归属原表 owner，但如果你用不同用户做 attach，权限链就断了。更隐蔽的是表空间路径：如果原分区在非默认表空间，detached 表仍留在原位置，但 attach 时若没显式指定 TABLESPACE，PostgreSQL 会试图把它挪到目标表的默认表空间——可能触发跨磁盘复制，卡住数小时。
- detach 前用
SELECT reltablespace FROM pg_class WHERE relname = 'xxx';记下表空间 ID - attach 时加上
FOR VALUES FROM (...) TO (...)和TABLESPACE xxx，确保路径一致 - 确认执行用户对两个表空间都有
CREATE权限，否则 attach 报permission denied for tablespace
最麻烦的不是操作本身，是 detach 后忘了记录表名、约束内容、表空间和统计时间——等一周后想 attach，就得翻日志、比对 DDL、重跑 analyze，停机窗口就出来了。
