前往新版Gitcode，体验更适合开发者的 AI 搜索 >>
## 67.4.实施 [67.4.1. 快速更新技术](gin-implementation.html#GIN-FAST-UPDATE) [67.4.2. 部分匹配算法](gin-implementation.html#GIN-PARTIAL-MATCH) 在内部，GIN索引包含在键上构造的B树索引，其中每个键都是一个或多个索引项（例如，数组的一个成员）的元素，叶页中的每个元组都包含指向堆指针的B树的指针（“发布树”），或者一个简单的堆指针列表（“发布列表”），当列表足够小，可以与键值一起放入一个索引元组时。[图67.1](gin-implementation.html#GIN-INTERNALS-FIGURE)说明了GIN索引的这些组件。 从PostgreSQL 9.1开始，索引中可以包含空键值。此外，占位符null也包含在索引中，用于索引为null或不包含键的索引项`提取值`。这允许搜索应该查找空项目的内容。 多列GIN索引是通过在复合值（列号、键值）上构建单个B树来实现的。不同列的键值可以是不同的类型。 **图67.1。杜松子酒** ### 67.4.1.快速更新技术 由于反向索引的本质，更新GIN索引的速度往往很慢：插入或更新一个堆行可能会导致多次插入索引（从索引项中提取的每个键对应一个）。GIN可以通过将新元组插入到一个临时的、未排序的待处理项列表中来推迟大部分工作。当表格被抽真空或自动分析时，或者`杜松子酒清洁待处理清单`函数，或者如果挂起列表大于[杜松子酒\_悬而未决的\_列表\_限度](runtime-config-client.html#GUC-GIN-PENDING-LIST-LIMIT)，使用初始索引创建期间使用的相同批量插入技术将条目移动到主GIN数据结构。这大大提高了GIN索引的更新速度，甚至计算了额外的真空开销。此外，开销工作可以通过后台进程而不是前台查询处理来完成。 这种方法的主要缺点是，除了搜索常规索引外，搜索还必须扫描待处理项列表，因此大量待处理项列表将显著降低搜索速度。另一个缺点是，虽然大多数更新都很快，但导致挂起列表变得“太大”的更新会导致立即的清理周期，因此比其他更新慢得多。正确使用自动真空可以最大限度地减少这两个问题。 如果一致的响应时间比更新速度更重要，可以通过关闭`快速更新`GIN索引的存储参数。看见[创建索引](sql-createindex.html)详细信息。 ### 67.4.2.部分匹配算法 GIN可以支持“部分匹配”查询，在这种查询中，查询不会确定一个或多个键的精确匹配，但可能的匹配属于合理狭窄的键值范围（在`比较`支持方法）。这个`提取查询`方法，而不是返回要精确匹配的键值，而是返回一个键值，该键值是要搜索的范围的下限，并设置`P匹配`这是真的。然后使用`比较部分`方法`比较部分`对于匹配的索引键，必须返回零；对于仍在要搜索的范围内的非匹配项，必须返回小于零；如果索引键超出了可以匹配的范围，则必须返回大于零。
