# 57.3\. 實現 在內部，GIN索引包含一個在鍵上構造的B-tree索引， 每個鍵是一個或多個被索引項目的一個元素(比如，一個數組的一個成員) 。 并且葉子頁上每個元組包含了或者堆指針的B-tree的一個指針（一個"posting tree"）， 或者，當列表小到足以和鍵值一起存儲到一個索引元組中時，則是堆指針的一個簡單列表（一個"posting list"）， 從PostgreSQL 9.1開始，NULL的鍵值可以被包含到索引里。 對NULL的或根據`extractValue`不包含任何鍵的被索引項，占位符null被包含到了索引中。 這就允許應該找到空項目的搜索可以執行。 多列GIN索引通過在組合值（列號，鍵值）上建立一個單個的B-tree實現。 不同列的鍵值可以有不同的類型。 ## 57.3.1\. GIN快速更新技術 由于倒排索引的本質特性，更新一個GIN索引可能會比較慢。 插入或更新一個堆行可能導致許多往索引的插入（從被索引項目中抽取出的每一個鍵一個）。 從PostgreSQL 8.4開始， GIN可以通過插入新的元組到一個臨時的，待處理實體的未排序列表，來推遲很多這樣的工作。 當表被vacuumed，或者如果待處理實體的列表太大了（大于[work_mem](#calibre_link-1374)）， 這些實體被使用和初始索引創建時用到的相同的bulk插入方法，移動到主要的GIN數據結構。 即使把額外的vacuum開銷算進去，這也大大提升了GIN索引更新的速度。 而且，這種額外開銷的工作可以通過后臺進程而不是前端查詢來處理。 這種方法的主要缺點在于搜索時除了常規的索引還必須要掃描待處理實體的列表。 因此，大的待處理實體的列表會顯著的拖慢搜索。 另一個缺點是，雖然大多數更新很快，一個導致待處理列表(pending list)變得"太大"的更新將引發一個立即的清理周期， 并因此比起其它更新會非常慢。 恰當的使用autovacuum可以最小化這兩個問題。 如果一致的響應時間比更新速度更重要，可以通過把GIN 索引的存儲參數`FASTUPDATE`設置為off而不使用待處理實體。 詳細請參考[CREATE INDEX](#calibre_link-83)。 ## 57.3.2\. 部分匹配算法 GIN可以支持"部分匹配"查詢。即：查詢并不決定單個或多個鍵的一個精確的匹配， 而是，可能的匹配落在一個合理的狹窄鍵值范圍內（根據`compare`支持函數決定的鍵值排序順序）。 此時，`extractQuery`方法并不返回一個用于精確匹配的鍵值，取而代之的是， 返回一個要被搜索的鍵值范圍的下邊界，并且設置`pmatch`為true。 然后，這個鍵值范圍被使用`comparePartial`進行掃描。 `comparePartial`必須為一個相匹配的索引鍵返回0，不匹配但依然在被搜索范圍內時返回小于0的值，對超過可以匹配的范圍的索引鍵則返回大于0的值。