↑↓ 选择 ↵ 打开 ⌫ 改范围 完整检索页

pgsql.cc 提供对 postgresql.org 官网内容的中文翻译,由 Pigsty 团队维护。

百科 / 执行计划节点 / 排序

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 标签

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

相关条目

文档与源码

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

版本比较

PostgreSQL 17 → 18: 无变化。

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

相关条目

导出 JSON · 返回执行计划节点 · 收录范围为 PostgreSQL 10 至 20;最早采样版本不一定是实际引入版本。