{"Entry":{"collection":"plan","key":"index-scan","name":"Index Scan","aliases":["Index Scan","IndexScan","T_IndexScan"],"metadata":{"aliases":["Index Scan","IndexScan","T_IndexScan"],"category":"Scan","content_hash":"f53ebc4a90679a398a8018bbd906d3fd30a00f8375f009e7068d9db7115abadf","derived_content_hash":"b70dec938285bea397d77bdc05a42a783078b74b7863008c7bfe6613b440bc2c","imported_at":"2026-09-30T00:40:44.228084+08:00","name":"Index Scan","name_zh":"IndexScan","slug":"index-scan","summary":"Uses an index to identify table tuples and fetches them from the relation."}},"Definition":{"Collection":"plan","Key":"index-scan","SourceDatabase":"center","Version":"18","SourceTable":"plan_node","SourceKey":"index-scan","SourceRevision":"555610c24d53e4316da5b7d3fc25c279d96856d5e0e23ee308c328c5fa881d9f","Facts":{"comparison_data":{"initializer":"ExecInitIndexScan","memory_mechanism":"unclassified","node_tag":"T_IndexScan","parallel_callbacks":["ExecIndexScanEstimate","ExecIndexScanInitializeDSM","ExecIndexScanInitializeWorker","ExecIndexScanReInitializeDSM","ExecIndexScanRetrieveInstrumentation"],"partial_modes":[],"strategies":[],"text_names":["Index Scan"]},"comparison_hash":"bff6d57534571534f7bc51a46aeea96e7625a417c3e00e43facf5de0097b2963","description":["Uses an index to identify table tuples and fetches them from the relation."],"description_zh":"通过索引定位表元组，再从关系中获取元组。","description_zh_html":"\u003cp\u003e通过索引定位表元组，再从关系中获取元组。\u003c/p\u003e\u003cp\u003e核心节点标识：\u003ccode\u003eT_IndexScan\u003c/code\u003e；EXPLAIN 名称：\u003ccode\u003eIndex Scan\u003c/code\u003e。\u003c/p\u003e\u003cp\u003e本版本源码中的并行执行或观测回调：\u003ccode\u003eExecIndexScanEstimate, ExecIndexScanInitializeDSM, ExecIndexScanInitializeWorker, ExecIndexScanReInitializeDSM, ExecIndexScanRetrieveInstrumentation\u003c/code\u003e。回调的存在不表示该节点必然支持共享并行扫描；在并行工作进程中执行也不等于具有并行感知能力。\u003c/p\u003e\u003ch3\u003e同版本中文手册节选\u003c/h3\u003e\u003cp\u003e\n    查询计划的结构是一棵由\u003cem class=\"firstterm\"\u003e计划节点\u003c/em\u003e组成的树。树的最底层是扫描节点，它们从表中返回原始行。不同的表访问方法对应不同类型的扫描节点，例如顺序扫描、索引扫描和位图索引扫描。也有一些并非表的行来源，例如 \u003ccode class=\"literal\"\u003eVALUES\u003c/code\u003e 子句和 \u003ccode class=\"literal\"\u003eFROM\u003c/code\u003e 中的返回集合函数，它们也各自有对应的扫描节点类型。如果查询需要对原始行执行连接、聚合、排序或其他操作，那么扫描节点之上还会出现额外的节点来完成这些操作。同样，这些操作通常不止一种实现方式，因此这里也会出现不同的节点类型。\u003ccode class=\"command\"\u003eEXPLAIN\u003c/code\u003e 会为计划树中的每个节点输出一行，显示基本节点类型以及规划器对该计划节点执行代价的估计值。还可能出现相对节点摘要行缩进的附加行，用来显示该节点的更多属性。第一行，也就是最顶层节点的摘要行，给出了整个计划的估计总执行代价；规划器力图最小化的正是这个数字。\n   \u003c/p\u003e\u003cp\u003e\n    下面是一个简单的示例，仅用于展示输出的样子：\n\n\u003c/p\u003e\u003cp\u003e\n    由于这个查询没有 \u003ccode class=\"literal\"\u003eWHERE\u003c/code\u003e 子句，它必须扫描表中的所有行，因此规划器选择了一个简单的顺序扫描计划。圆括号中的数字从左到右依次表示：\n\n    \u003c/p\u003e\u003cp\u003e\n    这些代价使用由规划器代价参数决定的任意单位来衡量（见\u003ca class=\"xref\" href=\"/zh/docs/18/runtime-config-query.html#RUNTIME-CONFIG-QUERY-CONSTANTS\"\u003e第 19.7.2 节\u003c/a\u003e）。传统上通常以磁盘页读取作为代价单位；也就是说，惯例上将 \u003ca class=\"xref\" href=\"/zh/docs/18/runtime-config-query.html#GUC-SEQ-PAGE-COST\"\u003eseq_page_cost\u003c/a\u003e 设为 \u003ccode class=\"literal\"\u003e1.0\u003c/code\u003e，其他代价参数都相对它来设定。本节中的示例都使用默认代价参数。\n   \u003c/p\u003e\u003cp\u003e\u003ca href=\"/zh/docs/18/using-explain.html#USING-EXPLAIN-BASICS\"\u003e查看完整中文手册与上下文\u003c/a\u003e。\u003c/p\u003e\u003cp\u003e本页开头的中文说明为 PG.CENTER 对编辑说明的翻译；手册节选保留对应版本中文文档原文。源码信息及手册示例不代表重新进行过运行测试。\u003c/p\u003e","evidence_kind":"source and documentation","explain_names":["Index Scan"],"explain_prefixes":["Parallel","Async"],"facts":[{"label":"Core node tag","value":"T_IndexScan"},{"label":"Structured EXPLAIN Node Type","value":"Index Scan"},{"label":"Inputs","value":"An index and its relation"},{"label":"Output","value":"Qualified table tuples"},{"label":"Executor initializer","value":"ExecInitIndexScan"},{"label":"Memory mechanism","value":"unclassified"}],"facts_zh":[{"label":"核心节点标签","value":"T_IndexScan"},{"label":"结构化 EXPLAIN 节点类型","value":"Index Scan"},{"label":"输入","value":"索引及所属关系"},{"label":"输出","value":"满足条件的表元组"},{"label":"执行器初始化函数","value":"ExecInitIndexScan"},{"label":"内存机制","value":"unclassified"}],"memory":{"description":"This extraction does not assign a universal memory limit or spill policy to this node. Inspect the same-build implementation and its expressions or provider.","evidence":[{"archive_sha256":"555610c24d53e4316da5b7d3fc25c279d96856d5e0e23ee308c328c5fa881d9f","label":"src/backend/executor/nodeIndexscan.c","path":"src/backend/executor/nodeIndexscan.c","sha256":"7bd7ad26dc403544b67a5b151cb28157f135e87733e78204c8b279f2ceb8f4dc","url":"https://ftp.postgresql.org/pub/source/v18.6/postgresql-18.6.tar.bz2"}],"mechanism":"unclassified","source_notes":["If the index was lossy, we have to recheck the index quals using the fetched tuple.","If the index was lossy, we have to recheck the index quals and ORDER BY expressions using the fetched tuple."]},"node_tag":"T_IndexScan","parallel_callbacks":["ExecIndexScanEstimate","ExecIndexScanInitializeDSM","ExecIndexScanInitializeWorker","ExecIndexScanReInitializeDSM","ExecIndexScanRetrieveInstrumentation"],"partial_modes":[],"related":[{"label":"EXPLAIN","url":"/wiki/sql/explain/?v=18"},{"label":"Using EXPLAIN","url":"/docs/18/using-explain.html"},{"label":"Parallel plans","url":"/docs/18/parallel-plans.html"},{"label":"enable_indexscan","url":"/wiki/guc/enable_indexscan/?v=18"},{"label":"random_page_cost","url":"/wiki/guc/random_page_cost/?v=18"},{"label":"Index AM","url":"/wiki/indexam/?v=18"}],"release":{"channel":"stable","label":"18.6","major":"18","ref":"PostgreSQL 18.6 source archive","revision":"555610c24d53e4316da5b7d3fc25c279d96856d5e0e23ee308c328c5fa881d9f","source_snapshot_utc":"","source_url":"https://ftp.postgresql.org/pub/source/v18.6/postgresql-18.6.tar.bz2"},"runtime_verified":false,"sections":[{"paragraphs":["Structured formats use the Node Type above. Text-format spellings can also include operation, strategy, join type, scan direction or aggregation-stage attributes.","Text names recorded by this source: Index Scan.","Parallel-aware and parallel-safe are different plan properties. A node running inside a parallel worker is not necessarily a parallel-aware node."],"title":"EXPLAIN names and attributes"},{"paragraphs":["This extraction does not assign a universal memory limit or spill policy to this node. Inspect the same-build implementation and its expressions or provider.","If the index was lossy, we have to recheck the index quals using the fetched tuple.","If the index was lossy, we have to recheck the index quals and ORDER BY expressions using the fetched tuple."],"title":"Memory and temporary storage"},{"paragraphs":["The source callbacks below can coordinate execution or collect worker instrumentation. Their presence is not a blanket claim that this node supports a shared parallel scan or shared state.","Callbacks in this build: ExecIndexScanEstimate, ExecIndexScanInitializeDSM, ExecIndexScanInitializeWorker, ExecIndexScanReInitializeDSM, ExecIndexScanRetrieveInstrumentation."],"title":"Parallel execution and instrumentation"},{"paragraphs":["This is the same query as above, but we added a LIMIT so that not all the rows need be retrieved, and the planner changed its mind about what to do. Notice that the total cost and row count of the Index Scan node are shown as if it were run to completion. However, the Limit node is expected to stop after retrieving only a fifth of those rows, so its total cost is only a fifth as much, and that's the actual estimated cost of the query. This plan is preferred over adding a Limit node to the previous plan because the Limit could not avoid paying the startup cost of the bitmap scan, so the total cost would be something over 25 units with that approach.","Notice that here the planner has chosen to “ materialize ” the inner relation of the join, by putting a Materialize plan node atop it. This means that the t2 index scan will be done just once, even though the nested-loop join node needs to read that data ten times, once for each row from the outer relation. The Materialize node saves the data in memory as it's read, and then returns the data from memory on each subsequent pass.","Merge join requires its input data to be sorted on the join keys. In this example each input is sorted by using an index scan to visit the rows in the correct order; but a sequential scan and sort could also be used. (Sequential-scan-and-sort frequently beats an index scan for sorting many rows, because of the nonsequential disk access required by the index scan.)","In some query plans, it is possible for a subplan node to be executed more than once. For example, the inner index scan will be executed once per outer row in the above nested-loop plan. In such cases, the loops value reports the total number of executions of the node, and the actual time and rows values shown are averages per-execution. This is done to make the numbers comparable with the way that the cost estimates are shown. Multiply by the loops value to get the total time actually spent in the node. In the above example, we spent a total of 0.030 milliseconds executing the index scans on tenk2 .","Index Scan nodes (as well as Bitmap Index Scan and Index-Only Scan nodes) show an “ Index Searches ” line that reports the total number of searches across all node executions/ loops :","Here we see a Bitmap Index Scan node that needed 4 separate index searches. The scan had to search the index from the tenk1_thous_tenthous index root page once per integer value from the predicate's IN construct. However, the number of index searches often won't have such a simple correspondence to the query predicate:"],"title":"Same-version manual discussion"},{"blocks":[{"code":"EXPLAIN SELECT * FROM tenk1 WHERE unique1 \u003c 100;\n\n                                  QUERY PLAN\n------------------------------------------------------------------------------\n Bitmap Heap Scan on tenk1  (cost=5.06..224.98 rows=100 width=244)\n   Recheck Cond: (unique1 \u003c 100)\n   -\u003e  Bitmap Index Scan on tenk1_unique1  (cost=0.00..5.04 rows=100 width=0)\n         Index Cond: (unique1 \u003c 100)","paragraphs":["Example copied from the PostgreSQL 18.6 manual; it was not executed for this collection.","Now, let's make the condition more restrictive:"],"source":{"label":"PostgreSQL 18.6 · using-explain","path":"using-explain.html","sha256":"60040c30180093418a0affe56dd27dff9df2504b705b38039589e458bf5c31ed","url":"/docs/18/using-explain.html#USING-EXPLAIN-BASICS"}},{"code":"EXPLAIN SELECT * FROM tenk1 WHERE unique1 \u003c 100 AND stringu1 = 'xxx';\n\n                                  QUERY PLAN\n------------------------------------------------------------------------------\n Bitmap Heap Scan on tenk1  (cost=5.04..225.20 rows=1 width=244)\n   Recheck Cond: (unique1 \u003c 100)\n   Filter: (stringu1 = 'xxx'::name)\n   -\u003e  Bitmap Index Scan on tenk1_unique1  (cost=0.00..5.04 rows=100 width=0)\n         Index Cond: (unique1 \u003c 100)","paragraphs":["Example copied from the PostgreSQL 18.6 manual; it was not executed for this collection.","Now let's add another condition to the WHERE clause:"],"source":{"label":"PostgreSQL 18.6 · using-explain","path":"using-explain.html","sha256":"60040c30180093418a0affe56dd27dff9df2504b705b38039589e458bf5c31ed","url":"/docs/18/using-explain.html#USING-EXPLAIN-BASICS"}}],"title":"Examples from this manual build"},{"paragraphs":["nodeIndexscan.c Routines to support indexed scans of relations","When an ordering operator is used, tuples fetched from the index that need to be reordered are queued in a pairing heap, as ReorderTuples.","Retrieve a tuple from the IndexScan node's currentRelation using the index specified in the IndexScanState information.","Determine which direction to scan the index in based on the plan's scan direction and the current direction of execution.","We reach here if the index scan is not parallel, or if we're serially executing an index scan that was planned to be parallel."],"title":"Executor implementation notes"},{"code":"case T_IndexScan:\n\t\t\tpname = sname = \"Index Scan\";\n\t\t\tbreak;","title":"EXPLAIN identity in core source"}],"sections_zh":[{"paragraphs":["结构化格式使用上述 Node Type。文本格式名称还可能包含操作、策略、连接类型、扫描方向或聚合阶段属性。","此源码记录的文本名称：Index Scan.","并行感知与并行安全是不同的计划属性。在并行工作进程内运行的节点不一定是并行感知节点。"],"title":"EXPLAIN 名称与属性"},{"paragraphs":["本次抽取不为此节点设定统一的内存上限或落盘策略。请查看同一构建的实现、相关表达式或提供方。","如果索引是有损的，必须使用获取的元组重新检查索引条件。","如果索引是有损的，必须使用获取的元组重新检查索引条件和 ORDER BY 表达式。"],"title":"内存与临时存储"},{"paragraphs":["以下源码回调可以协调执行或收集工作进程的测量数据。回调存在不代表该节点普遍支持共享并行扫描或共享状态。","此构建的回调：ExecIndexScanEstimate, ExecIndexScanInitializeDSM, ExecIndexScanInitializeWorker, ExecIndexScanReInitializeDSM, ExecIndexScanRetrieveInstrumentation."],"title":"并行执行与运行信息采集"},{"paragraphs":["查询与上例相同，只是增加 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 索引的根页开始搜索一次。不过，索引搜索次数往往不会与查询谓词存在如此简单的对应关系："],"title":"同版本手册说明"},{"blocks":[{"code":"EXPLAIN SELECT * FROM tenk1 WHERE unique1 \u003c 100;\n\n                                  QUERY PLAN\n------------------------------------------------------------------------------\n Bitmap Heap Scan on tenk1  (cost=5.06..224.98 rows=100 width=244)\n   Recheck Cond: (unique1 \u003c 100)\n   -\u003e  Bitmap Index Scan on tenk1_unique1  (cost=0.00..5.04 rows=100 width=0)\n         Index Cond: (unique1 \u003c 100)","paragraphs":["示例摘自 PostgreSQL 18.6 手册；本百科未实际执行此示例。","现在进一步收紧条件："],"source":{"label":"PostgreSQL 18.6 · using-explain","path":"using-explain.html","sha256":"60040c30180093418a0affe56dd27dff9df2504b705b38039589e458bf5c31ed","url":"/docs/18/using-explain.html#USING-EXPLAIN-BASICS"}},{"code":"EXPLAIN SELECT * FROM tenk1 WHERE unique1 \u003c 100 AND stringu1 = 'xxx';\n\n                                  QUERY PLAN\n------------------------------------------------------------------------------\n Bitmap Heap Scan on tenk1  (cost=5.04..225.20 rows=1 width=244)\n   Recheck Cond: (unique1 \u003c 100)\n   Filter: (stringu1 = 'xxx'::name)\n   -\u003e  Bitmap Index Scan on tenk1_unique1  (cost=0.00..5.04 rows=100 width=0)\n         Index Cond: (unique1 \u003c 100)","paragraphs":["示例摘自 PostgreSQL 18.6 手册；本百科未实际执行此示例。","现在向 WHERE 子句再添加一个条件："],"source":{"label":"PostgreSQL 18.6 · using-explain","path":"using-explain.html","sha256":"60040c30180093418a0affe56dd27dff9df2504b705b38039589e458bf5c31ed","url":"/docs/18/using-explain.html#USING-EXPLAIN-BASICS"}}],"title":"本版手册中的示例"},{"paragraphs":["nodeIndexscan.c：支持关系索引扫描的例程。","使用排序操作符时，从索引取回且需要重新排序的元组会以 ReorderTuples 形式排入配对堆。","通过 IndexScanState 指定的索引，从 IndexScan 节点的 currentRelation 中读取元组。","根据计划的扫描方向和当前执行方向，确定索引扫描方向。","索引扫描不并行执行，或原计划并行的索引扫描以串行方式执行时，会到达此处。"],"title":"执行器实现说明"},{"code":"case T_IndexScan:\n\t\t\tpname = sname = \"Index Scan\";\n\t\t\tbreak;","title":"核心源码中的 EXPLAIN 标识"}],"source_inventory":{"executor":"src/backend/executor/execProcnode.c","explain":"src/backend/commands/explain.c","implementation":"src/backend/executor/nodeIndexscan.c"},"sources":[{"archive_sha256":"555610c24d53e4316da5b7d3fc25c279d96856d5e0e23ee308c328c5fa881d9f","label":"src/backend/commands/explain.c:1444","line":1444,"path":"src/backend/commands/explain.c","sha256":"34c86d6070224a0e981efef51f79101d6d505e5874f1684ace183034bab14bb4","url":"https://ftp.postgresql.org/pub/source/v18.6/postgresql-18.6.tar.bz2"},{"archive_sha256":"555610c24d53e4316da5b7d3fc25c279d96856d5e0e23ee308c328c5fa881d9f","label":"src/backend/executor/execProcnode.c:219","line":219,"path":"src/backend/executor/execProcnode.c","sha256":"f8a06a3f539077249b20664b2812433db6d7bd12b2c0ca633525db43d06f112a","url":"https://ftp.postgresql.org/pub/source/v18.6/postgresql-18.6.tar.bz2"},{"archive_sha256":"555610c24d53e4316da5b7d3fc25c279d96856d5e0e23ee308c328c5fa881d9f","label":"src/backend/executor/nodeIndexscan.c","path":"src/backend/executor/nodeIndexscan.c","sha256":"7bd7ad26dc403544b67a5b151cb28157f135e87733e78204c8b279f2ceb8f4dc","url":"https://ftp.postgresql.org/pub/source/v18.6/postgresql-18.6.tar.bz2"},{"archive_sha256":"555610c24d53e4316da5b7d3fc25c279d96856d5e0e23ee308c328c5fa881d9f","label":"src/include/nodes/plannodes.h","path":"src/include/nodes/plannodes.h","sha256":"52422b327a8049fbbb20d8b96008a0fc0a6fafa60f7eff3c695d5b2e83830120","url":"https://ftp.postgresql.org/pub/source/v18.6/postgresql-18.6.tar.bz2"},{"label":"PostgreSQL 18.6 · using-explain","path":"using-explain.html","sha256":"60040c30180093418a0affe56dd27dff9df2504b705b38039589e458bf5c31ed","url":"/docs/18/using-explain.html#USING-EXPLAIN-BASICS"},{"label":"PostgreSQL 18.6 · using-explain","path":"using-explain.html","sha256":"60040c30180093418a0affe56dd27dff9df2504b705b38039589e458bf5c31ed","url":"/docs/18/using-explain.html#USING-EXPLAIN-ANALYZE"}],"strategies":[],"tables":[{"columns":[{"key":"label","label":"Text-format label"},{"key":"identity","label":"Structured node identity"}],"key":"explain-labels","rows":[{"identity":"Index Scan","label":"Index Scan"}],"title":"EXPLAIN labels in this source build"}],"tables_zh":[{"columns":[{"key":"label","label":"文本格式标签"},{"key":"identity","label":"结构化节点标识"}],"key":"explain-labels","rows":[{"identity":"Index Scan","label":"Index Scan"}],"title":"本构建中的 EXPLAIN 标签"}],"zh_from":{"authored_translation":"authored-translation-of-reviewed-guidance","body_sha256":"c189988ce4d3fb8fbcb1ecda4728e96a2021153fac942edebf28985e9251eeeb","kind":"same-version-chinese-manual-with-authored-translation-of-reviewed-guidance","manual":{"anchor":"USING-EXPLAIN-BASICS","build_id":107,"extraction":"concept-introduction","fragment_sha256":"bc79b6f9c70f2b56968e08ea26d2c9ec3d395e425aca0594e227203daa0ad29b","locale":"zh-Hans","page_key":"using-explain.html","source_hash":"d2f749744b3ac5aa2eb0154f295e8163903cd20fcc130c74c6172cdf2ae3a9df","source_revision":"unknown:rendered-translation-baseline","translated_from_revision":null,"translation_revision":"git:b1b500221dbe5437cfca004d6b04d3f6e422765d;html-sha256:08e987a66af27b98444a8057c256314eafa13611a3fb9e888214fc436824244b","url":"/zh/docs/18/using-explain.html#USING-EXPLAIN-BASICS","version":"18"},"runtime_rerun":false,"source_facts_revision":"555610c24d53e4316da5b7d3fc25c279d96856d5e0e23ee308c328c5fa881d9f"}},"ManualEvidence":{"release":{"channel":"stable","label":"18.6","major":"18","ref":"PostgreSQL 18.6 source archive","revision":"555610c24d53e4316da5b7d3fc25c279d96856d5e0e23ee308c328c5fa881d9f","source_snapshot_utc":"","source_url":"https://ftp.postgresql.org/pub/source/v18.6/postgresql-18.6.tar.bz2"},"sources":[{"archive_sha256":"555610c24d53e4316da5b7d3fc25c279d96856d5e0e23ee308c328c5fa881d9f","label":"src/backend/commands/explain.c:1444","line":1444,"path":"src/backend/commands/explain.c","sha256":"34c86d6070224a0e981efef51f79101d6d505e5874f1684ace183034bab14bb4","url":"https://ftp.postgresql.org/pub/source/v18.6/postgresql-18.6.tar.bz2"},{"archive_sha256":"555610c24d53e4316da5b7d3fc25c279d96856d5e0e23ee308c328c5fa881d9f","label":"src/backend/executor/execProcnode.c:219","line":219,"path":"src/backend/executor/execProcnode.c","sha256":"f8a06a3f539077249b20664b2812433db6d7bd12b2c0ca633525db43d06f112a","url":"https://ftp.postgresql.org/pub/source/v18.6/postgresql-18.6.tar.bz2"},{"archive_sha256":"555610c24d53e4316da5b7d3fc25c279d96856d5e0e23ee308c328c5fa881d9f","label":"src/backend/executor/nodeIndexscan.c","path":"src/backend/executor/nodeIndexscan.c","sha256":"7bd7ad26dc403544b67a5b151cb28157f135e87733e78204c8b279f2ceb8f4dc","url":"https://ftp.postgresql.org/pub/source/v18.6/postgresql-18.6.tar.bz2"},{"archive_sha256":"555610c24d53e4316da5b7d3fc25c279d96856d5e0e23ee308c328c5fa881d9f","label":"src/include/nodes/plannodes.h","path":"src/include/nodes/plannodes.h","sha256":"52422b327a8049fbbb20d8b96008a0fc0a6fafa60f7eff3c695d5b2e83830120","url":"https://ftp.postgresql.org/pub/source/v18.6/postgresql-18.6.tar.bz2"},{"label":"PostgreSQL 18.6 · using-explain","path":"using-explain.html","sha256":"60040c30180093418a0affe56dd27dff9df2504b705b38039589e458bf5c31ed","url":"/docs/18/using-explain.html#USING-EXPLAIN-BASICS"},{"label":"PostgreSQL 18.6 · using-explain","path":"using-explain.html","sha256":"60040c30180093418a0affe56dd27dff9df2504b705b38039589e458bf5c31ed","url":"/docs/18/using-explain.html#USING-EXPLAIN-ANALYZE"}]},"MeasuredEvidence":{"runtime_verified":false}},"Text":{"Collection":"plan","Key":"index-scan","SourceDatabase":"center","Version":"18","Locale":"en","Title":"Index Scan","Summary":"Uses an index to identify table tuples and fetches them from the relation.","BodyHTML":"\u003cp\u003eUses an index to identify table tuples and fetches them from the relation.\u003c/p\u003e","SourceRevision":"555610c24d53e4316da5b7d3fc25c279d96856d5e0e23ee308c328c5fa881d9f","ContentHash":"ed123664a9f0900ed772d143de23386c7f4d542a469c72449f4a804e4b80d8b3","Payload":{"description":["Uses an index to identify table tuples and fetches them from the relation."],"related":[{"label":"EXPLAIN","url":"/wiki/sql/explain/?v=18"},{"label":"Using EXPLAIN","url":"/docs/18/using-explain.html"},{"label":"Parallel plans","url":"/docs/18/parallel-plans.html"},{"label":"enable_indexscan","url":"/wiki/guc/enable_indexscan/?v=18"},{"label":"random_page_cost","url":"/wiki/guc/random_page_cost/?v=18"},{"label":"Index AM","url":"/wiki/indexam/?v=18"}],"sections":[{"paragraphs":["Structured formats use the Node Type above. Text-format spellings can also include operation, strategy, join type, scan direction or aggregation-stage attributes.","Text names recorded by this source: Index Scan.","Parallel-aware and parallel-safe are different plan properties. A node running inside a parallel worker is not necessarily a parallel-aware node."],"title":"EXPLAIN names and attributes"},{"paragraphs":["This extraction does not assign a universal memory limit or spill policy to this node. Inspect the same-build implementation and its expressions or provider.","If the index was lossy, we have to recheck the index quals using the fetched tuple.","If the index was lossy, we have to recheck the index quals and ORDER BY expressions using the fetched tuple."],"title":"Memory and temporary storage"},{"paragraphs":["The source callbacks below can coordinate execution or collect worker instrumentation. Their presence is not a blanket claim that this node supports a shared parallel scan or shared state.","Callbacks in this build: ExecIndexScanEstimate, ExecIndexScanInitializeDSM, ExecIndexScanInitializeWorker, ExecIndexScanReInitializeDSM, ExecIndexScanRetrieveInstrumentation."],"title":"Parallel execution and instrumentation"},{"paragraphs":["This is the same query as above, but we added a LIMIT so that not all the rows need be retrieved, and the planner changed its mind about what to do. Notice that the total cost and row count of the Index Scan node are shown as if it were run to completion. However, the Limit node is expected to stop after retrieving only a fifth of those rows, so its total cost is only a fifth as much, and that's the actual estimated cost of the query. This plan is preferred over adding a Limit node to the previous plan because the Limit could not avoid paying the startup cost of the bitmap scan, so the total cost would be something over 25 units with that approach.","Notice that here the planner has chosen to “ materialize ” the inner relation of the join, by putting a Materialize plan node atop it. This means that the t2 index scan will be done just once, even though the nested-loop join node needs to read that data ten times, once for each row from the outer relation. The Materialize node saves the data in memory as it's read, and then returns the data from memory on each subsequent pass.","Merge join requires its input data to be sorted on the join keys. In this example each input is sorted by using an index scan to visit the rows in the correct order; but a sequential scan and sort could also be used. (Sequential-scan-and-sort frequently beats an index scan for sorting many rows, because of the nonsequential disk access required by the index scan.)","In some query plans, it is possible for a subplan node to be executed more than once. For example, the inner index scan will be executed once per outer row in the above nested-loop plan. In such cases, the loops value reports the total number of executions of the node, and the actual time and rows values shown are averages per-execution. This is done to make the numbers comparable with the way that the cost estimates are shown. Multiply by the loops value to get the total time actually spent in the node. In the above example, we spent a total of 0.030 milliseconds executing the index scans on tenk2 .","Index Scan nodes (as well as Bitmap Index Scan and Index-Only Scan nodes) show an “ Index Searches ” line that reports the total number of searches across all node executions/ loops :","Here we see a Bitmap Index Scan node that needed 4 separate index searches. The scan had to search the index from the tenk1_thous_tenthous index root page once per integer value from the predicate's IN construct. However, the number of index searches often won't have such a simple correspondence to the query predicate:"],"title":"Same-version manual discussion"},{"blocks":[{"code":"EXPLAIN SELECT * FROM tenk1 WHERE unique1 \u003c 100;\n\n                                  QUERY PLAN\n------------------------------------------------------------------------------\n Bitmap Heap Scan on tenk1  (cost=5.06..224.98 rows=100 width=244)\n   Recheck Cond: (unique1 \u003c 100)\n   -\u003e  Bitmap Index Scan on tenk1_unique1  (cost=0.00..5.04 rows=100 width=0)\n         Index Cond: (unique1 \u003c 100)","paragraphs":["Example copied from the PostgreSQL 18.6 manual; it was not executed for this collection.","Now, let's make the condition more restrictive:"],"source":{"label":"PostgreSQL 18.6 · using-explain","path":"using-explain.html","sha256":"60040c30180093418a0affe56dd27dff9df2504b705b38039589e458bf5c31ed","url":"/docs/18/using-explain.html#USING-EXPLAIN-BASICS"}},{"code":"EXPLAIN SELECT * FROM tenk1 WHERE unique1 \u003c 100 AND stringu1 = 'xxx';\n\n                                  QUERY PLAN\n------------------------------------------------------------------------------\n Bitmap Heap Scan on tenk1  (cost=5.04..225.20 rows=1 width=244)\n   Recheck Cond: (unique1 \u003c 100)\n   Filter: (stringu1 = 'xxx'::name)\n   -\u003e  Bitmap Index Scan on tenk1_unique1  (cost=0.00..5.04 rows=100 width=0)\n         Index Cond: (unique1 \u003c 100)","paragraphs":["Example copied from the PostgreSQL 18.6 manual; it was not executed for this collection.","Now let's add another condition to the WHERE clause:"],"source":{"label":"PostgreSQL 18.6 · using-explain","path":"using-explain.html","sha256":"60040c30180093418a0affe56dd27dff9df2504b705b38039589e458bf5c31ed","url":"/docs/18/using-explain.html#USING-EXPLAIN-BASICS"}}],"title":"Examples from this manual build"},{"paragraphs":["nodeIndexscan.c Routines to support indexed scans of relations","When an ordering operator is used, tuples fetched from the index that need to be reordered are queued in a pairing heap, as ReorderTuples.","Retrieve a tuple from the IndexScan node's currentRelation using the index specified in the IndexScanState information.","Determine which direction to scan the index in based on the plan's scan direction and the current direction of execution.","We reach here if the index scan is not parallel, or if we're serially executing an index scan that was planned to be parallel."],"title":"Executor implementation notes"},{"code":"case T_IndexScan:\n\t\t\tpname = sname = \"Index Scan\";\n\t\t\tbreak;","title":"EXPLAIN identity in core source"}],"tables":[{"columns":[{"key":"label","label":"Text-format label"},{"key":"identity","label":"Structured node identity"}],"key":"explain-labels","rows":[{"identity":"Index Scan","label":"Index Scan"}],"title":"EXPLAIN labels in this source build"}]}},"RequestedLocale":"en","Fallback":false,"Versions":["10","11","12","13","14","15","16","17","18","19","20"],"Locales":["en","zh-Hans"],"Signatures":null,"Spellings":null,"SQLState":null,"Evidence":null}