由于每个项目可能插入多个键，因此插入到 GIN 索引中可能会很慢。因此，对于表中的批量插入，建议删除 GIN 索引并在完成批量插入后重新创建它。

当为 GIN 启用 fastupdate 时（有关详细信息，请参阅 第 70.4.1 节），与未启用时相比，损失更小。但对于非常大的更新，最好还是删除并重新创建索引。

GIN 索引的构建时间对 maintenance_work_mem 设置非常敏感；在索引创建期间，不要吝惜工作内存。

在对启用了 fastupdate 的现有 GIN 索引进行一系列插入期间，当列表增长到大于 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）效果很好。