給定要索引的專案，返回一個 palloc 分配的鍵陣列。返回的鍵的數量必須儲存在*nkeys中。如果任何鍵可以為空，則還要 palloc 分配一個包含*nkeys個bool欄位的陣列，將其地址儲存在*nullFlags中，並根據需要設定這些空標誌。*nullFlags可以保留為NULL（其初始值），如果所有鍵都非空。如果專案不包含鍵，則返回值可以為NULL。

給定要查詢的值，返回一個 palloc 分配的鍵陣列；也就是說，query是可索引運算子的右側值，其左側是索引列。n是運算子類中運算子的策略編號（請參閱第 36.16.2 節）。通常，extractQuery需要查閱n以確定query的資料型別以及它應該用於提取鍵值的方法。返回的鍵的數量必須儲存在*nkeys中。如果任何鍵可以為空，則還要 palloc 分配一個包含*nkeys個bool欄位的陣列，將其地址儲存在*nullFlags中，並根據需要設定這些空標誌。*nullFlags可以保留為NULL（其初始值），如果所有鍵都非空。如果query不包含鍵，則返回值可以為NULL。

searchMode是一個輸出引數，允許extractQuery指定搜尋的詳細資訊。如果*searchMode設定為GIN_SEARCH_MODE_DEFAULT（這是呼叫前初始化的值），則只有與至少一個返回鍵匹配的專案才被視為候選匹配。如果*searchMode設定為GIN_SEARCH_MODE_INCLUDE_EMPTY，則除了包含至少一個匹配鍵的專案外，不包含任何鍵的專案也被視為候選匹配。（此模式對於實現子集運算子等非常有用。）如果*searchMode設定為GIN_SEARCH_MODE_ALL，則索引中所有非空專案都被視為候選匹配，無論它們是否與任何返回鍵匹配。（此模式比其他兩種選擇慢得多，因為它需要掃描幾乎整個索引，但可能需要正確實現邊緣情況。在大多數情況下需要此模式的運算子可能不適合作為 GIN 運算子類。）用於設定此模式的符號在access/gin.h中定義。

pmatch是一個輸出引數，用於支援部分匹配。要使用它，extractQuery必須分配一個包含*nkeys個bool的陣列，並將其地址儲存在*pmatch中。陣列的每個元素應設定為 true，如果相應的鍵需要部分匹配，否則設定為 false。如果*pmatch設定為NULL，則 GIN 假定不需要部分匹配。該變數在呼叫前初始化為NULL，因此不支援部分匹配的運算子類可以簡單地忽略此引數。

extra_data是一個輸出引數，允許extractQuery將附加資料傳遞給consistent和comparePartial方法。要使用它，extractQuery必須分配一個包含*nkeys個指標的陣列，並將其地址儲存在*extra_data中，然後將它想要的任何內容儲存到各個指標中。該變數在呼叫前初始化為NULL，因此不需要額外資料的運算子類可以簡單地忽略此引數。如果設定了*extra_data，則整個陣列將傳遞給consistent方法，並將相應的元素傳遞給comparePartial方法。

如果索引項滿足策略編號為n的查詢運算子（或者如果返回重新檢查指示，則可能滿足），則返回 true。此函式無法直接訪問索引項的值，因為GIN不顯式儲存項。相反，可用的是關於從查詢中提取的哪些鍵值出現在給定索引項中的知識。check陣列的長度為nkeys，與之前為該query資料項由extractQuery返回的鍵數相同。如果索引項包含相應的查詢鍵，則check陣列的每個元素都為 true，即如果 (check[i] == true) 則extractQuery結果陣列的第 i 個鍵存在於索引項中。原始query資料項被傳入，以防consistent方法需要查閱它，同時傳入的還有之前由extractQuery返回的queryKeys[]和nullFlags[]陣列。extra_data是extractQuery返回的附加資料陣列，如果沒有則為NULL。

當extractQuery在queryKeys[]中返回空鍵時，如果索引項包含空鍵，則相應的check[]元素為真；也就是說，check[]的語義類似於IS NOT DISTINCT FROM。如果需要區分常規值匹配和空匹配，consistent函式可以檢查相應的nullFlags[]元素。

成功時，如果需要根據查詢運算子重新檢查堆元組，則應將*recheck設定為 true，如果索引測試是精確的，則設定為 false。也就是說，返回 false 值保證堆元組不匹配查詢；返回 true 值且*recheck設定為 false 保證堆元組匹配查詢；返回 true 值且*recheck設定為 true 表示堆元組可能匹配查詢，因此需要透過直接針對原始索引項評估查詢運算子來獲取和重新檢查它。

triConsistent類似於consistent，但在check向量中，每個鍵有三個可能的值：GIN_TRUE、GIN_FALSE和GIN_MAYBE。GIN_FALSE和GIN_TRUE與常規布林值具有相同的含義，而GIN_MAYBE表示該鍵的存在未知。當存在GIN_MAYBE值時，如果專案肯定匹配，無論索引項是否包含相應的查詢鍵，函式才應返回GIN_TRUE。同樣，函式只有在專案肯定不匹配時才必須返回GIN_FALSE，無論它是否包含GIN_MAYBE鍵。如果結果取決於GIN_MAYBE條目，即基於已知查詢鍵無法確認或否定匹配，則函式必須返回GIN_MAYBE。

當check向量中沒有GIN_MAYBE值時，GIN_MAYBE返回值等同於在布林型consistent函式中設定recheck標誌。

比較兩個鍵（而不是索引項！），並返回一個小於零、等於零或大於零的整數，指示第一個鍵是小於、等於還是大於第二個鍵。空鍵永遠不會傳遞給此函式。

比較部分匹配查詢鍵與索引鍵。返回一個整數，其符號表示結果：小於零表示索引鍵與查詢不匹配，但索引掃描應繼續；零表示索引鍵與查詢匹配；大於零表示索引掃描應停止，因為不再可能匹配。提供了生成部分匹配查詢的運算子的策略編號n，以防需要其語義來確定何時結束掃描。此外，extra_data是extractQuery建立的附加資料陣列的相應元素，如果沒有則為NULL。空鍵永遠不會傳遞給此函式。

定義一組使用者可見的引數，用於控制運算子類的行為。

options函式傳遞一個指向local_relopts結構的指標，該結構需要填充一組運算子類特定選項。可以使用PG_HAS_OPCLASS_OPTIONS()和PG_GET_OPCLASS_OPTIONS()宏從其他支援函式訪問這些選項。

由於索引值的鍵提取和鍵在GIN中的表示都是靈活的，它們可能取決於使用者指定的引數。

插入到GIN索引可能很慢，因為每個專案可能會插入許多鍵。因此，對於批次插入表，建議在完成批次插入後刪除 GIN 索引並重新建立它。

當為GIN啟用fastupdate時（有關詳細資訊，請參閱第 65.4.4.1 節），開銷會小於未啟用時。但對於非常大的更新，最好還是刪除並重新建立索引。

構建時間GIN索引對maintenance_work_mem設定非常敏感；在索引建立期間節省工作記憶體是得不償失的。

在對已啟用fastupdate的現有GIN索引進行一系列插入期間，系統將在待處理條目列表大於gin_pending_list_limit時清理該列表。為避免觀察到的響應時間波動，最好讓待處理列表清理在後臺（即透過自動清理）進行。可以透過增加gin_pending_list_limit或使自動清理更積極地避免前臺清理操作。但是，增加清理操作的閾值意味著，如果確實發生前臺清理，則需要更長時間。

gin_pending_list_limit可以透過更改儲存引數來覆蓋單個 GIN 索引，這允許每個 GIN 索引擁有自己的清理閾值。例如，可以僅為可能被大量更新的 GIN 索引增加閾值，並否則降低它。

開發的主要目標GIN索引是為了在PostgreSQL中建立對高度可擴充套件的全文字搜尋的支援，並且通常情況下，全文字搜尋會返回非常大的結果集。此外，當查詢包含非常頻繁的單詞時，這通常會發生，因此大型結果集甚至沒有用。由於從磁碟讀取許多元組並對其進行排序可能需要很長時間，這對於生產來說是不可接受的。（請注意，索引搜尋本身非常快。）

為了方便對此類查詢進行受控執行，GIN對返回的行數有一個可配置的軟上限：gin_fuzzy_search_limit配置引數。它預設設定為 0（表示無限制）。如果設定了非零限制，則返回的結果集是整個結果集的子集，隨機選擇。

“軟”意味著實際返回的結果數量可能與指定限制略有不同，具體取決於查詢和系統隨機數生成器的質量。

根據經驗，數千個值（例如，5000 — 20000）效果很好。

B 樹等效功能，適用於多種資料型別

用於儲存（鍵，值）對的模組

對int[]的增強支援

使用三元組匹配進行文字相似度