1、问题描述
GaussDB有表膨胀的问题，业务有张表，膨胀了1.4TB，膨胀率高达98%, 表里目前有的数据差不多100w多点，由于磁盘空间告警，而且暂时无法扩容，需要重建表膨胀的问题来缓解磁盘空间。
2、问题分析
表膨胀问题很严重，需要进行处理，处理的方案通常有三种：
2.1 开源工具：pg_repack
--资源不可控，有可能获取锁失败
2.2 Guassdb内置的命令vacuum full --会锁表，阻塞表上的DML
--会锁表，阻塞表上的DML
2.3 手动重建表
纯sql脚本，过程可控，会丢失更新数据，跟业务沟通后影响不大，最多就是修复几条脏数据
最终采用手动重建表的方式来做，执行完之后，需要删除1.4TB的老表的时候，执行了50min都没完成，怀疑是锁等导致的，于是就去看了下pg_stat_activity视图果然发现有一个
autovacuum: VACUUM PG_TOAST.PG_TOAST_12345； 通过select * from pg_class where oid = 12345查询得知正是正在执行drop的表，由于这表有有Text大字段，当内容超过块大小8K时就会启动TOAST，将大的字段压缩或切片成多个物理行存到另一张系统表中（TOAST表）。
通过分析了明白了是执行vacuum toast表的进程阻塞了执行drop table的进程，于是杀掉vacuum进程之后，drop table的操作瞬间完成，在后台df -h看磁盘是在缓慢释放的。
3、总结
删除大表的时候，可以考虑设置alter table xxx set (autovacuum_enabled=off);关闭autovacuum之后，再进行删除操作，其实pg_repack也是建议先设置为off，再执行膨胀回收，不然也会锁表。
