百科 / 执行计划节点 / 扫描

Index Scan

IndexScan

通过索引定位表元组，并从关系中获取元组。

当前查看 PostgreSQL 18.6。

说明

通过索引定位表元组，并从关系中获取元组。

核心节点标签: T_IndexScan
结构化 EXPLAIN 节点类型: Index Scan
输入: 索引及所属关系
输出: 满足条件的表元组
执行器初始化函数: ExecInitIndexScan
内存机制: unclassified

EXPLAIN 名称与属性

结构化格式使用上述 Node Type。文本格式名称还可能包含操作、策略、连接类型、扫描方向或聚合阶段属性。

此源码记录的文本名称：Index Scan.

并行感知与并行安全是不同的计划属性。在并行工作进程内运行的节点不一定是并行感知节点。

内存与临时存储

本次抽取不为此节点设定统一的内存上限或落盘策略。请查看同一构建的实现、相关表达式或提供方。

如果索引是有损的，必须使用获取的元组重新检查索引条件。

如果索引是有损的，必须使用获取的元组重新检查索引条件和 ORDER BY 表达式。

并行执行与运行信息采集

以下源码回调可以协调执行或收集工作进程的测量数据。回调存在不代表该节点普遍支持共享并行扫描或共享状态。

此构建的回调：ExecIndexScanEstimate, ExecIndexScanInitializeDSM, ExecIndexScanInitializeWorker, ExecIndexScanReInitializeDSM, ExecIndexScanRetrieveInstrumentation.

同版本手册说明

查询与上例相同，只是增加 LIMIT，不再需要取回全部行，因此规划器改变了选择。Index Scan 节点的总成本和行数仍按完整执行显示，但 Limit 预计只取回五分之一的行就停止，其总成本也只有五分之一，这才是查询的实际估计成本。与在此前计划上添加 Limit 相比，此计划更优，因为 Limit 无法避免位图扫描的启动成本，原方案的总成本仍会超过 25 个单位。

规划器在连接内侧关系之上加入 Materialize 节点，将其物化。因此，尽管嵌套循环连接需要为外侧的每一行读取一次内侧数据、共十次，t2 的索引扫描也只执行一次。Materialize 在读取时将数据保存在内存中，后续各轮直接从内存返回数据。

归并连接要求输入数据按连接键排序。在这个例子中，两个输入都通过索引扫描按正确顺序访问行而完成排序；不过也可以采用顺序扫描再排序的方式。（对于需要排序很多行的情况，顺序扫描加排序往往会胜过索引扫描，因为索引扫描需要非顺序磁盘访问。）

在某些查询计划中，一个子计划节点可能会执行多次。例如，上面那个嵌套循环计划中的内侧索引扫描会对外侧的每一行执行一次。在这种情况下， loops 值报告的是该节点的总执行次数，而 actual time 和 rows 显示的是每次执行的平均值。这样做是为了让这些数字更容易与代价估计的展示方式相比较。将它们乘以 loops 值，就能得到该节点实际消耗的总时间。在上面的示例中，执行 tenk2 上的索引扫描总共花费了 0.030 毫秒。

Index Scan 节点（以及 Bitmap Index Scan 和 Index-Only Scan 节点）会显示一行 “ Index Searches ” ，用于报告跨所有节点执行/ loops 的总搜索次数：

这里的 Bitmap Index Scan 节点需要分别执行 4 次索引搜索。对于谓词 IN 结构中的每个整数值，扫描都需要从 tenk1_thous_tenthous 索引的根页开始搜索一次。不过，索引搜索次数往往不会与查询谓词存在如此简单的对应关系：

本版手册中的示例

示例摘自 PostgreSQL 18.6 手册；本百科未实际执行此示例。

现在进一步收紧条件：

EXPLAIN SELECT * FROM tenk1 WHERE unique1 < 100;

                                  QUERY PLAN
------------------------------------------------------------------------------
 Bitmap Heap Scan on tenk1  (cost=5.06..224.98 rows=100 width=244)
   Recheck Cond: (unique1 < 100)
   ->  Bitmap Index Scan on tenk1_unique1  (cost=0.00..5.04 rows=100 width=0)
         Index Cond: (unique1 < 100)

示例摘自 PostgreSQL 18.6 手册；本百科未实际执行此示例。

现在向 WHERE 子句再添加一个条件：

EXPLAIN SELECT * FROM tenk1 WHERE unique1 < 100 AND stringu1 = 'xxx';

                                  QUERY PLAN
------------------------------------------------------------------------------
 Bitmap Heap Scan on tenk1  (cost=5.04..225.20 rows=1 width=244)
   Recheck Cond: (unique1 < 100)
   Filter: (stringu1 = 'xxx'::name)
   ->  Bitmap Index Scan on tenk1_unique1  (cost=0.00..5.04 rows=100 width=0)
         Index Cond: (unique1 < 100)

执行器实现说明

nodeIndexscan.c：支持关系索引扫描的例程。

使用排序操作符时，从索引取回且需要重新排序的元组会以 ReorderTuples 形式排入配对堆。

通过 IndexScanState 指定的索引，从 IndexScan 节点的 currentRelation 中读取元组。

根据计划的扫描方向和当前执行方向，确定索引扫描方向。

索引扫描不并行执行，或原计划并行的索引扫描以串行方式执行时，会到达此处。

核心源码中的 EXPLAIN 标识

case T_IndexScan:
			pname = sname = "Index Scan";
			break;

本构建中的 EXPLAIN 标签

文本格式标签	结构化节点标识
Index Scan	Index Scan

文档与源码

来源构建

版本: 18.6
构建: PostgreSQL 18.6 source archive
来源指纹: 555610c24d53e4316da5b7d3fc25c279d96856d5e0e23ee308c328c5fa881d9f

版本比较

PostgreSQL 17 → 18: 属性变化。

以下差异保留原始字段名与英文源描述。

--- PostgreSQL 17
+++ PostgreSQL 18
@@ -6,7 +6,8 @@
     "ExecIndexScanEstimate",
     "ExecIndexScanInitializeDSM",
     "ExecIndexScanInitializeWorker",
-    "ExecIndexScanReInitializeDSM"
+    "ExecIndexScanReInitializeDSM",
+    "ExecIndexScanRetrieveInstrumentation"
   ],
   "partial_modes": [],
   "strategies": [],

比较已记录的接口与属性，排除来源指纹和构建元数据。某个样本中没有记录，不能据此判断实际引入或移除的版本。

快速链接