向 GIN 索引插入数据可能较慢，因为每个项很可能需要插入许多键。 因此，对于向表中执行的批量插入，建议先删除 GIN 索引，待批量插入完成后再重建它。

当为 GIN 启用 fastupdate 时 （详见 Section 65.4.1），这种代价会比未启用时小一些。 但对于非常大的更新，最好仍然是删除并重建索引。

GIN 索引的构建时间对 maintenance_work_mem 设置非常敏感；在创建索引时节省工作内存并不划算。

在对现有 GIN 索引执行一系列插入且其 fastupdate 已启用时，系统会在待处理列表增长到超过 gin_pending_list_limit 时清理该列表。 为避免观测到的响应时间波动，最好让待处理列表的清理在后台发生（即通过自动清理）。 可以通过增大 gin_pending_list_limit 或让自动清理更积极， 来避免前台清理操作。不过，提高清理触发阈值也意味着，一旦确实发生前台清理，耗时会更长。

可以通过更改存储参数为单个 GIN 索引覆盖 gin_pending_list_limit，从而让每个 GIN 索引拥有自己的清理阈值。 例如，可以只提高那些更新很频繁的 GIN 索引的阈值，而把其他索引的阈值调低。

开发 GIN 索引的主要目标，是为 PostgreSQL 中高度可伸缩的全文检索提供支持，而全文检索返回一个非常大的结果集的情况也很常见。 此外，当查询包含非常常见的词时，通常也会出现这种情况，以至于这个大型结果集本身并无多大用处。 由于从磁盘读取大量元组并对其排序可能需要很长时间，这在生产环境中是不可接受的。 （注意，索引搜索本身是非常快的。）

为了便于受控地执行这类查询，GIN 对返回行数设置了一个可配置的软上限， 即配置参数 gin_fuzzy_search_limit。默认值为 0（表示无限制）。 如果设置了非零限制，那么返回集合将是整个结果集的一个随机子集。

“软”的意思是，实际返回结果的数量可能会与指定的限制略有不同， 这取决于查询以及系统随机数生成器的质量。

根据经验，数千量级的值（例如 5000 — 20000）效果不错。