# 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)可以工作得很好。