# 67.5.
杜松子酒提示和技巧创建与插入
由于可能为每个项目插入许多键,因此插入 GIN 索引可能会很慢。因此,对于表中的批量插入,建议删除 GIN 索引并在完成批量插入后重新创建它。
什么时候快速更新
为 GIN 启用(请参阅第 67.4.1 节详情),惩罚比没有的时候少。但是对于非常大的更新,最好还是删除并重新创建索引。
GIN 索引的构建时间对维护工作内存
环境;在创建索引期间节省工作内存是不值得的。
在一系列插入现有 GIN 索引的过程中,该索引具有快速更新
启用后,只要列表大于gin_pending_list_limit
.为了避免观察到的响应时间出现波动,最好在后台(即通过 autovacuum)进行挂起列表清理。可以通过增加来避免前台清理操作gin_pending_list_limit
或使 autovacuum 更具侵略性。但是,扩大清理操作的阈值意味着如果确实发生了前台清理,则需要更长的时间。
gin_pending_list_limit
可以通过更改存储参数来覆盖单个 GIN 索引,这允许每个 GIN 索引有自己的清理阈值。例如,可以仅对可以大量更新的 GIN 索引增加阈值,否则降低阈值。
开发 GIN 索引的主要目标是在 PostgreSQL 中创建对高度可扩展的全文搜索的支持,并且经常出现全文搜索返回非常大的结果集的情况。此外,当查询包含非常频繁的单词时,通常会发生这种情况,因此大型结果集甚至没有用处。由于从磁盘读取许多元组并对其进行排序可能会花费大量时间,因此这对于生产来说是不可接受的。(请注意,索引搜索本身非常快。)
为了促进此类查询的受控执行,GIN 对返回的行数有一个可配置的软上限:gin_fuzzy_search_limit
配置参数。默认设置为 0(表示无限制)。如果设置了非零限制,则返回的集合是整个结果集的子集,随机选择。
“软”意味着返回结果的实际数量可能与指定的限制有所不同,具体取决于查询和系统随机数生成器的质量。
根据经验,以千为单位的值(例如,5000 - 20000)效果很好。