在内部，
GIN 索引包含一个在键上构造的B-tree 索引，
每个键是一个或多个被索引项的
一个元素（比如，一个数组的一个成员）。并且页面上每个元组包含了堆指针的B-tree 的一
个指针（一个posting tree），当列表小到足以和键值一起存储到一个索引元组中时，则是堆
指针的一个简单列表（一个posting list）。
多列GIN 索引通过在组合值（列号、键值）上建立一个单个的B-tree 实现。不同列的
键值可以有不同的类型。
GIN 快速更新技术
GBase 8c SQL 参考手册
南大通用数据技术股份有限公司
1282
由于倒排索引的本身特性影响，更新一个GIN 索引可能会比较慢。插入或更新一个堆
行可能导致许多往索引的插入。
当对表执行VACUUM 后，
或者如果待处理实体的列表太大
了（大于work_mem），这些实体被使用和初始索引创建时用到的相同的bulk 插入方法，
移动到主要的GIN 数据结构。即使把额外的VACUUM 开销算进去，这也大大提升了GIN
索引更新的速度。而且，这种额外开销的工作可以通过后台进程而不是前端查询来处理。
这种方法的主要缺点在于搜索时除了常规的索引还必须要扫描待处理实体的列表。因
此，大的待处理实体的列表会显著的拖慢搜索。另一个缺点是，虽然大多数更新很快，但是
一个导致待处理列表（pending list）变得“太大”的更新将引发一个立即清理，并因此比起
其它更新会非常慢。恰当的使用autovacuum 可以弱化这两个问题。
如果一致的响应时间（清理实体速度和更新速度的响应时间）比更新速度更重要，
可以
通过把GIN 索引的存储参数FASTUPDATE 设置为off 而不使用待处理实体。详细请参考
CREATE INDEX。
部分匹配算法
GIN 可以支持“部分匹配”查询。即：查询并不决定单个或多个键的一个精确的匹配，
而是，
可能的匹配落在一个合理的狭窄键值范围内
（根据compare 支持函数决定的键值排序
顺序）。此时，extractQuery 方法并不返回一个用于精确匹配的键值，取而代之的是，返回
一个要被搜索的键值范围的下边界，并且设置pmatch 为true。然后，使用comparePartial 方
式扫描这个键值范围。
comparePartial 必须为一个相匹配的索引键返回0，
如果不匹配但依然
在被搜索范围内时返回小于0 的值，对超过可以匹配的范围的索引键则返回大于0 的值。