PostgreSQL全表更新执行缓慢，现有优化方案是否为官方推荐做法？

我正从SQL Server迁移到Postgres，遇到了一个非常基础的问题，搜索了一段时间后已经解决，但不确定我采取的方案是否是官方推荐的做法！

我有一张简单的表，包含id整数列、tags数组列和一个jsonb列。
我在tags数组字段上建立了Gin索引，查询记录的性能非常好，该表仅有约13万行数据。
我遇到了更新速度极慢的问题：只是一个非常简单的给数组列追加数值的操作，需要全表更新13万行，我补充说明这一点，因为我之前没给大家说清楚，完成更新居然花了大约2分钟！
我查阅了更多PostgreSQL相关资料后了解到，因为我要更新每一行，PostgreSQL几乎会重建整张表。
所以我做了两件事：

ALTER TABLE mytable SET (FILLFACTOR = 50);
VACUUM FULL mytable;

而且每次执行更新操作前，我都会先删除gin索引，执行更新后再重建索引。
优化后更新总耗时从2分钟降到了2~3秒。
我认为删除索引可以支持HOT update所以解决了问题，但我的问题是：这是处理这类场景的官方推荐做法吗？

解答 #

你的优化方案符合PostgreSQL的性能优化逻辑，属于全表更新场景下的常规可行方案，核心优化点的生效逻辑如下：

• 删索引再重建的操作是性能提升的核心原因：全表更新时每行变更都会同步触发索引写入，GIN索引的写入开销远高于普通B树索引，13万次增量索引写入的开销远高于一次全量索引重建的开销。
• 调低fillfactor的操作在高频小批量更新场景下会有更明显的收益，你这个全表更新场景下HOT更新并不会生效——因为你更新的tags字段本身是GIN索引的关联字段，索引必须同步更新，所以HOT机制没法跳过索引写入步骤。

如果你的全表更新操作是低频执行的（比如每月/每周一次），当前方案已经是最优选择，没有额外副作用。如果是高频执行的日常操作，可以考虑把更新拆分为多批次小事务提交，每次更新几千行，避免长时间锁表影响业务查询。

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