61.5. GIN 提示和技巧

插入到一个GIN索引可能会很慢， 因为为一个项可能需要插入很多个键。因此，对于一个表的批量插入， 我们建议删除 GIN 索引，然后在完成批量插入后重建它。

从PostgreSQL 8.4 开始，这个建议已经不再需要了， 因为可以使用延迟索引（详见第 61.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）比较好。