Sort
Sort
按照计划中的排序键对子计划输出行排序。
当前查看 PostgreSQL 18。
中文定义与说明
按照计划中的排序键对子计划输出行排序。
核心节点标识:T_Sort;EXPLAIN 名称:Sort。
本版本源码中的并行执行或观测回调:ExecSortEstimate, ExecSortInitializeDSM, ExecSortInitializeWorker, ExecSortRetrieveInstrumentation。回调的存在不表示该节点必然支持共享并行扫描;在并行工作进程中执行也不等于具有并行感知能力。
同版本中文手册节选
查询计划的结构是一棵由计划节点组成的树。树的最底层是扫描节点,它们从表中返回原始行。不同的表访问方法对应不同类型的扫描节点,例如顺序扫描、索引扫描和位图索引扫描。也有一些并非表的行来源,例如 VALUES 子句和 FROM 中的返回集合函数,它们也各自有对应的扫描节点类型。如果查询需要对原始行执行连接、聚合、排序或其他操作,那么扫描节点之上还会出现额外的节点来完成这些操作。同样,这些操作通常不止一种实现方式,因此这里也会出现不同的节点类型。EXPLAIN 会为计划树中的每个节点输出一行,显示基本节点类型以及规划器对该计划节点执行代价的估计值。还可能出现相对节点摘要行缩进的附加行,用来显示该节点的更多属性。第一行,也就是最顶层节点的摘要行,给出了整个计划的估计总执行代价;规划器力图最小化的正是这个数字。
下面是一个简单的示例,仅用于展示输出的样子:
由于这个查询没有 WHERE 子句,它必须扫描表中的所有行,因此规划器选择了一个简单的顺序扫描计划。圆括号中的数字从左到右依次表示:
这些代价使用由规划器代价参数决定的任意单位来衡量(见第 19.7.2 节)。传统上通常以磁盘页读取作为代价单位;也就是说,惯例上将 seq_page_cost 设为 1.0,其他代价参数都相对它来设定。本节中的示例都使用默认代价参数。
本页开头的中文说明为 PG.CENTER 对编辑说明的翻译;手册节选保留对应版本中文文档原文。源码信息及手册示例不代表重新进行过运行测试。
说明
按照计划中的排序键对子计划输出行排序。
- 核心节点标签
- T_Sort
- 结构化 EXPLAIN 节点类型
- Sort
- 输入
- 一个子计划
- 输出
- 已排序的元组
- 执行器初始化函数
- ExecInitSort
- 内存机制
- tuplesort
EXPLAIN 名称与属性
结构化格式使用上述 Node Type。文本格式名称还可能包含操作、策略、连接类型、扫描方向或聚合阶段属性。
此源码记录的文本名称:Sort.
并行感知与并行安全是不同的计划属性。在并行工作进程内运行的节点不一定是并行感知节点。
内存与临时存储
此节点将 work_mem 传给 tuplesort。排序可使用内存或临时文件;实际方法和空间用量取决于输入及计划。
使用 tuplesort 对节点外侧子树的元组排序,将结果保存在临时文件或内存中。首次调用之后,每次调用都从文件返回一个元组。
并行执行与运行信息采集
以下源码回调可以协调执行或收集工作进程的测量数据。回调存在不代表该节点普遍支持共享并行扫描或共享状态。
此构建的回调:ExecSortEstimate, ExecSortInitializeDSM, ExecSortInitializeWorker, ExecSortRetrieveInstrumentation.
同版本手册说明
估计启动代价:输出阶段开始之前消耗的时间,例如排序节点执行排序所需的时间。
规划器可以用多种方式实现 ORDER BY 子句。上面的示例表明,这种排序子句可以被隐式满足。规划器也可能显式增加一个 Sort 步骤:
如果计划中的某一部分已经保证了所需排序键前缀的顺序,规划器也可能改用 Incremental Sort 步骤:
归并连接要求输入数据按连接键排序。在这个例子中,两个输入都通过索引扫描按正确顺序访问行而完成排序;不过也可以采用顺序扫描再排序的方式。(对于需要排序很多行的情况,顺序扫描加排序往往会胜过索引扫描,因为索引扫描需要非顺序磁盘访问。)
在某些情况下,EXPLAIN ANALYZE 除了计划节点的执行时间和行数之外,还会显示额外的执行统计信息。例如,Sort 和 Hash 节点会提供更多信息:
Sort 节点显示排序方法(尤其是内存排序还是磁盘排序)及所需内存或磁盘空间。Hash 节点显示哈希桶数、批次数及哈希表内存使用峰值。(批次数超过一时也会使用磁盘空间,但此处不显示。)
本版手册中的示例
示例摘自 PostgreSQL 18.6 手册;本百科未实际执行此示例。
规划器可以用多种方式实现 ORDER BY 子句。上面的示例表明,这种排序子句可以被隐式满足。规划器也可能显式增加一个 Sort 步骤:
EXPLAIN SELECT * FROM tenk1 ORDER BY unique1;
QUERY PLAN
-------------------------------------------------------------------
Sort (cost=1109.39..1134.39 rows=10000 width=244)
Sort Key: unique1
-> Seq Scan on tenk1 (cost=0.00..445.00 rows=10000 width=244)示例摘自 PostgreSQL 18.6 手册;本百科未实际执行此示例。
如果计划中的某一部分已经保证了所需排序键前缀的顺序,规划器也可能改用 Incremental Sort 步骤:
EXPLAIN SELECT * FROM tenk1 ORDER BY hundred, ten LIMIT 100;
QUERY PLAN
------------------------------------------------------------------------------------------------
Limit (cost=19.35..39.49 rows=100 width=244)
-> Incremental Sort (cost=19.35..2033.39 rows=10000 width=244)
Sort Key: hundred, ten
Presorted Key: hundred
-> Index Scan using tenk1_hundred on tenk1 (cost=0.29..1574.20 rows=10000 width=244)执行器实现说明
使用 tuplesort 对节点外侧子树的元组排序,将结果保存在临时文件或内存中。首次调用之后,每次调用都从文件返回一个元组。
此排序可用两种不同方式执行:
1)结果只有一列时,执行 Datum 排序。
2)结果包含多列时,执行元组排序。
也可以始终执行元组排序,但仅对 Datum 排序可能显著更快,尤其当 Datum 属于按值传递的类型时。
核心源码中的 EXPLAIN 标识
case T_Sort:
pname = sname = "Sort";
break;本构建中的 EXPLAIN 标签
| 文本格式标签 | 结构化节点标识 |
|---|---|
| Sort | Sort |
相关条目
文档与源码
- src/backend/commands/explain.c:1522
- src/backend/executor/execProcnode.c:320
- src/backend/executor/nodeSort.c
- src/include/nodes/plannodes.h
- src/backend/utils/sort/tuplesort.c
- PostgreSQL 18.6 · using-explain
- PostgreSQL 18.6 · using-explain
来源构建
- 版本
- 18.6
- 构建
- PostgreSQL 18.6 source archive
- 来源指纹
555610c24d53e4316da5b7d3fc25c279d96856d5e0e23ee308c328c5fa881d9f
版本比较
PostgreSQL 17 → 18: 无变化。
比较已记录的接口与属性,排除来源指纹和构建元数据。某个样本中没有记录,不能据此判断实际引入或移除的版本。
相关条目
Incremental SortIncrementalSort
导出 JSON · 返回执行计划节点 · 收录范围为 PostgreSQL 10 至 20;最早采样版本不一定是实际引入版本。