PostgreSQL 14中TRUNCATE分区表必须指定具体分区名，不支持TRUNCATE TABLE parent_table PARTITION (p2023)语法；正确做法是将分区视为普通表，用TRUNCATE TABLE partition_name逐个清理，并注意权限、外键约束及事务自动提交特性。
TRUNCATE分区表时必须指定具体分区名
PostgreSQL 14不支持直接对分区父表执行 TRUNCATE TABLE parent_table（除非加 CASCADE，但那会级联清空所有子分区，通常不是你想要的）。你要逐个清理分区，就得明确写出每个分区的名称。
常见错误是误以为 TRUNCATE TABLE parent_table PARTITION (p2023) 这种语法存在——它根本不存在。PostgreSQL里没有 PARTITION 子句用于 TRUNCATE。
- 正确做法：把分区当作普通表对待，用
TRUNCATE TABLE partition_name - 分区名一般由系统生成（如
sales_2023_q1）或手动命名（如logs_y2024m01），可在pg_class或pg_inherits中查到 - 执行前务必确认该分区无外键引用，否则会报错：
ERROR: cannot truncate a table referenced in a foreign key constraint
如何批量生成TRUNCATE语句（避免手写）
手动列出几十个分区容易漏、易出错。推荐用查询动态拼出语句：
SELECT 'TRUNCATE TABLE ' || relname || ';'
FROM pg_class
WHERE relkind = 'r'
AND relname ~ '^logs_y2024m\d{2}$' -- 匹配你约定的分区命名模式
AND relname IN (
SELECT inhrelid::regclass::text
FROM pg_inherits
WHERE inhparent = 'logs'::regclass
)
ORDER BY relname;结果是一堆可复制粘贴的 TRUNCATE TABLE logs_y2024m01; 语句。注意两点：
-
relname ~ '^logs_y2024m\d{2}$'是正则匹配，确保只选中目标月份分区；不加锚点（^和$）可能误中类似logs_y2024m01_archived的表 - 子查询过滤掉非继承自
logs的同名表，防止误删独立表 - 如果分区用了 schema（比如
partitions.logs_y2024m01），记得在relname前补上 schema，或改用pg_namespace关联
TRUNCATE分区 vs DELETE + VACUUM 的实际差异
很多人想“先DELETE再VACUUM”，但在大分区场景下这是低效路径：
-
TRUNCATE是 DDL，立刻释放磁盘空间、重置序列、不走事务日志（WAL量极小），且不可回滚 -
DELETE是 DML，每行都记 WAL，锁整张分区表，之后还得显式VACUUM才能回收空间——对 TB 级分区，可能卡住数小时 - 唯一例外：分区上有
ON TRUNCATE触发器（PostgreSQL 14 不支持该触发器类型），所以目前无需担心触发器干扰 - 若需条件性清空（比如只删某状态数据），只能用
DELETE；但那就不是“逐个TRUNCATE”的范畴了
权限和事务边界要注意什么
TRUNCATE 需要目标分区上的 TRUNCATE 权限（默认 OWNER 或 superuser 拥有），不是 DELETE 权限就能替代。
- 不能在事务块里对多个分区连续
TRUNCATE后再COMMIT——每个TRUNCATE自动提交，无法回滚其中任意一个 - 如果中途某个分区被其他会话锁住（比如正在
INSERT），整个TRUNCATE会阻塞，直到锁释放；建议在低峰期操作 - 使用
TRUNCATE ... RESTART IDENTITY对分区无效（因为分区本身不带序列），只有父表定义了IDENTITY列时才需在父表级处理
真正麻烦的是跨 schema 分区和带继承链的多层分区——这时候 pg_inherits 查询逻辑得加多层递归，容易漏掉叶子节点。别图省事跳过验证步骤。
