直接删除某个月数据应使用 DROP TABLE 或 TRUNCATE TABLE 分区名，而非 DELETE WHERE，因前者秒级完成且不触发全表扫描、行锁与WAL膨胀；例如 TRUNCATE TABLE logs_202403 即可安全、原子地清空2024年3月分区。
为什么直接 DELETE 某个时间范围的数据会很慢？
因为普通表上按时间字段 DELETE 会触发全表扫描 + 行级锁 + WAL 日志写入 + 可能的 VACUUM 延迟，数据量大时可能卡住几小时。分区表的核心价值不是“让 SQL 更短”，而是让你能绕过这些开销——直接删整个分区。
如何创建支持按时间快速删除的分区表？
关键在分区键类型和分区策略选择。PostgreSQL 12+ 推荐使用声明式范围分区，时间字段必须是 DATE 或 TIMESTAMP 类型（不能是字符串），且主表需明确指定 PARTITION BY RANGE (created_at)。
PostgreSQL 18.4 ubuntu
下载
PostgreSQL 18.4 官方 Ubuntu 安装包现已发布，这是目前最新的稳定版本。推荐通过官方 APT 仓库安装：先执行 sudo apt update 更新索引，再运行 sudo apt install postgresql-18 即可完成部署。新版本引入了异步 I/O 子系统，在顺序扫描与 VACUUM 场景下性能提升显著，同时支持 UUID v7 原生生成函数与虚拟生成列。
- 建表时用
CREATE TABLE ... PARTITION BY RANGE (created_at)，别漏掉括号里的字段名 - 每个子分区必须用
FOR VALUES FROM ('2024-01-01') TO ('2024-02-01')精确覆盖，不能有空隙或重叠 - 避免用
TO MAXVALUE当最后一个分区——否则删它等于删全表，失去控制力 - 如果已有数据，先用
CREATE TABLE ... PARTITION OF ... FOR VALUES ...拆分，再用INSERT INTO ... SELECT迁移，别用ATTACH PARTITION直接挂载未校验的数据
怎样安全、原子地删除某个月的数据？
不是 DELETE FROM logs WHERE created_at >= '2024-03-01' AND created_at ，而是直接删分区本身。前提是：你清楚该分区名，且没被其他对象（如外键、物化视图）依赖。
- 查分区名：
SELECT relname FROM pg_class WHERE relkind = 'r' AND relname LIKE 'logs_2024_03%' - 删分区（立即生效，不走事务日志）：
DROP TABLE logs_2024_03 - 如果担心误删，先
RENAME TABLE logs_2024_03 TO logs_2024_03_dropped，观察一天再DROP - 注意：
DROP TABLE会释放磁盘空间，但若该分区上有索引或触发器，它们会随分区一起消失——不需要单独清理
删完分区后查询变慢？检查默认分区和统计信息
删掉旧分区后，如果查询条件落在已删范围内，PostgreSQL 仍会去检查那个分区（哪怕已不存在），导致 planner 误判执行计划。更隐蔽的问题是：ANALYZE 不会自动更新父表的统计信息，可能导致后续查询选错索引。
- 确认没有残留的
DEFAULT分区——它会吃掉所有未匹配的行，让分区裁剪失效 - 删完后立刻执行：
ANALYZE logs（对父表，不是子表） - 如果用了
pg_partman，检查其配置表part_config是否还记录着已删分区，否则下次run_maintenance()可能报错 - 应用层务必确保时间过滤条件与分区边界对齐，比如用
created_at >= '2024-05-01' AND created_at ，而不是 <code>BETWEEN——后者在边界值上可能跨分区
