# 57.4\. GIN提示与技巧 创建 vs 插入 由于可能要为每个项目插入很多键，所以GIN索引的插入可能比较慢。 对于向表中大量插入的操作，我们建议先删除GIN索引，在完成插入之后再重建它。 由于从PostgreSQL 8.4开始可以使用延迟索引了，这个建议已经没有那么必要了。 （详细请参考[Section 57.3.1](#calibre_link-751)。） 但是，对于非常大量的更新，最好还是先删除，而后再重建索引。 [maintenance_work_mem](#calibre_link-1150) GIN索引的构建时间对`maintenance_work_mem`的设置非常敏感。 它没有为在索引创建期间少使用工作内存做出努力。 [work_mem](#calibre_link-1374) 在一系列往已有的启用了`FASTUPDATE`的GIN索引的插入操作期间， 只要待处理实体列表的大小超过了`work_mem`，系统就会清理这个列表。 为了避免可观察到的响应时间的大起大落，让待处理实体列表在后台被清理是比较合适的（比如通过autovacuum）。 前台清理操作可以通过增加`work_mem`或者更加激进的autovacuum来避免。 然而，扩大`work_mem`意味着如果发生了前台清理，那么它的执行时间将更长。 [gin_fuzzy_search_limit](#calibre_link-1980) 开发GIN索引的主要目的是为了让PostgreSQL 支持高度可伸缩的全文索引，并且常常会遇见全文索引返回海量结果的情形。 而且，这经常发生在查询高频词的时候，因而得到的结果集没什么用处。 因为从磁盘读取大量记录并对其进行排序会消耗大量资源，这在产品环境下是不能接受的(注意，索引搜索本身是很快的)。 为了易于控制这种情况，GIN有一个可配置的返回结果行数的软上限配置参数 `gin_fuzzy_search_limit`。 缺省值 0 表示没有限制。如果设置了非零值，那么返回的结果就是从完整结果集中随机选择的一部分。 "软"的意思是实际返回的结果集大小可能与指定值稍有出入，具体取决于查询以及系统的随机数发生器的品质。 经验上，数千的值(比如5000 — 20000)可以工作得很好。