Postgresql 中文操作指南

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

当 GIN 为 _fastupdate_启用时（有关详细信息，请参见 Section 70.4.1），与不启用时相比，损失较小。但对于非常大的更新，最好仍然删除并重新创建索引。

GIN 索引的构建时间对 maintenance_work_mem 设置非常敏感；在索引创建期间不宜在工作内存上偷工减料。

在向已启用 fastupdate 的现有 GIN 索引进行一系列插入期间，只要列表增长超过 gin_pending_list_limit ，系统都会清理待处理条目列表。为了避免观察到的响应时间波动，最好在后台（即通过自动清理）进行待处理列表清理。可以通过增加 gin_pending_list_limit 或使自动清理更激进来避免前台清理操作。但是，扩大清理操作的阈值意味着，如果确实发生了前台清理，它将花费更长的时间。

可以通过更改存储参数来覆盖 gin_pending_list_limit 的各个 GIN 索引，这允许每个 GIN 索引拥有自己的清理阈值。例如，可以仅增加可以进行大量更新的 GIN 索引的阈值，否则会降低该阈值。

开发 GIN 索引的主要目标是为 PostgreSQL 中的高度可扩展全文搜索创建支持，并且经常会出现全文搜索返回非常大的一组结果的情况。而且，这种情况经常发生在查询包含非常频繁的单词时，因此大结果集甚至没有用。由于从磁盘读取许多元组并对其进行排序可能需要很长时间，因此这对于生产环境来说是不可接受的。（请注意，索引搜索本身非常快。）

为了促进此类查询的可控执行，GIN 对返回的行数具有可配置的柔软上限：gin_fuzzy_search_limit 配置参数。默认情况下，它设置为 0（表示没有限制）。如果设置了一个非零限制，那么返回的集合是整个结果集合的子集，随机选择。

“软”表示返回的实际结果数量可能根据查询和系统随机数生成器的质量与其指定限制有所不同。

根据经验，数千（例如 5000 - 20000）的值效果很好。