64.5. GIN 提示和技巧

• 创建与插入

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

从 PostgreSQL 8.4 开始，此建议已不再需要，因为使用了延迟索引(有关详细信息，请参见Section 64.4.1)。但是对于非常大的更新，仍然最好删除并重新创建索引。

• maintenance_work_mem

  • GIN 索引的构建时间对maintenance_work_mem设置非常敏感；创建索引期间无需花时间在工作内存上。

• gin_pending_list_limit

  • 在对已启用fastupdate的现有 GIN 索引进行一系列插入期间，只要列表的大小大于gin_pending_list_limit，系统都会清理该列表。为了避免观察到的响应时间波动，最好在后台(即通过自动真空)进行挂起列表清除。可以通过增加gin_pending_list_limit或使自动真空更具侵略性来避免前景清理操作。但是，增大清理操作的阈值意味着如果确实发生了前台清理，则将花费更长的时间。

可以通过更改存储参数来为单个 GIN 索引覆盖gin_pending_list_limit，这使每个 GIN 索引都有自己的清除阈值。例如，可以仅为可以大量更新的 GIN 索引增加阈值，否则可以降低阈值。

• gin_fuzzy_search_limit

  • 开发 GIN 索引的主要目的是在 PostgreSQL 中创建对高度可扩展的全文本搜索的支持，并且在许多情况下，全文本搜索返回非常多的结果。此外，当查询包含非常频繁的单词时，通常会发生这种情况，因此大型结果集甚至都没有用。由于从磁盘读取许多 Tuples 并对其进行排序可能会花费大量时间，因此这对于生产来说是不可接受的。 (请注意，索引搜索本身非常快.)

为了促进此类查询的受控执行，GIN 对于返回的行数具有可配置的软上限：gin_fuzzy_search_limit配置参数。默认情况下，它设置为 0(表示无限制)。如果设置了非零限制，则返回的集是整个结果集的子集，是随机选择的。

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

根据经验，成千上万的值(例如 5000 至 20000)效果很好。