pgsql.cc 提供对 postgresql.org 官网内容的中文翻译，由 Pigsty 团队维护。
向 GIN 索引插入数据可能较慢，因为每个值 很可能需要插入许多键。因此，对于向表中执行的批量插入，建议 先删除 GIN 索引，待批量插入完成后再重建它。
从PostgreSQL 8.4 开始，由于采用了延迟索引，这项建议已不那么必要（详见第 53.3.1 节）。但对于非常大的更新，删除并重建索引仍然可能是最佳选择。
GIN 索引的构建时间对 maintenance_work_mem 设置非常敏感；在创建索引时节省工作内存并不划算。
在对现有 GIN 索引执行一系列插入且其 FASTUPDATE 已启用时，系统会在待处理项列表增长到 超过 work_mem 时清理该列表。为避免观测到的响应 时间波动，最好让待处理列表的清理在后台发生（即通过自动清理）。 可以通过增大 work_mem 或让自动清理更积极，来避免 前台清理操作。不过，增大 work_mem 意味着一旦真的 发生前台清理，它耗时会更久。
开发 GIN 索引的首要目标，是为 PostgreSQL 中高度可扩展的全文搜索提供 支持，而全文搜索经常会返回非常大的结果集。此外，这种情况常 发生在查询包含非常高频的词时，因此庞大的结果集甚至没有用处。 由于从索引中读取许多 元组并对其排序可能需要很长时间，这在生产环境中是不可接受的。 （注意，索引搜索本身是非常快的。）
为了便于受控地执行这类查询，GIN 对返回行数 设置了一个可配置的软上限，即配置参数 gin_fuzzy_search_limit。默认值为 0（表示无 限制）。如果设置了非零限制，那么返回集合将是整个结果集的一个 随机子集。
“软”的意思是，实际返回结果的数量可能会与指定的 限制略有不同，这取决于查询以及系统随机数生成器的质量。
译文有误、术语不当或页面显示问题，请到译文仓库 pgsty/pgdoc 报告译文问题。 英文原文本身的问题，请在当前版本的对应页面向上游反馈；上游不再修订已结束维护的版本。