AWS RDS PostgreSQL autovacuum是否将空间归还至操作系统？

你的判断是正确的：默认开启的autovacuum等价于普通VACUUM操作，回收的空间默认仅允许被原表复用，不会主动归还操作系统。

核心细节说明 #

• autovacuum的本质：默认配置下，autovacuum执行的就是标准的VACUUM命令，而非VACUUM FULL。它的核心目标是清理死元组、更新统计信息，同时标记空闲空间供当前表后续使用。
• 普通VACUUM的空间逻辑：回收的空闲空间会被标记为"可复用"状态，但仅对当前表的插入、更新操作开放。只有当表的末尾存在连续的完全空闲页，且没有活跃事务引用这些页时，普通VACUUM才会尝试截断表的末尾，将这部分空间归还操作系统——但这种情况在有持续写入的大表中很难频繁出现。
• VACUUM FULL的不可替代性（但不适合你的场景）：正如你所说，VACUUM FULL会重写整个表，强制将所有空闲空间归还操作系统，但它需要ACCESS EXCLUSIVE锁（会阻塞所有表操作）、执行速度极慢，还需要额外的临时磁盘空间，完全不适合你的65GB+大表场景。

针对你的归档场景的建议 #

• 依赖autovacuum或手动触发VACUUM：每次归档完成后，autovacuum会自动清理归档产生的死元组，标记出的空闲空间可以被原表后续的写入操作复用，避免表体积持续膨胀。如果需要加速清理，可以手动执行VACUUM your_table;（无需锁表，不阻塞业务）。
• 改用分区表优化归档：如果需要彻底归还空间给操作系统，推荐将大表改为分区表结构。每次归档时，直接DROP对应历史分区——这种操作会立刻将分区占用的空间归还操作系统，且仅需要极短时间的锁，效率远高于VACUUM类操作，非常适合定期归档的场景。
• 调整autovacuum参数：根据表的归档频率和数据量，调整autovacuum_vacuum_threshold、autovacuum_vacuum_scale_factor等参数，确保归档后autovacuum能及时触发清理，避免死元组堆积。

内容的提问来源于stack exchange，提问作者gbro3n