合 《PostgreSQL技术内幕——原理探索》第三章 查询处理
Tags: PGPostgreSQL翻译《PostgreSQL技术内幕——原理探索》
- 3.1 概览
- 3.1.1 解析器(Parser)
- 3.1.2 分析器(Analyzer)
- 3.1.3 重写器(Rewriter)
- 视图
- 3.1.4 计划器与执行器
- pg_hint_plan
- 3.2 单表查询的代价估计
- 3.2.1 顺序扫描
- 3.2.2 索引扫描
- 3.2.2.1 启动代价
- 3.2.2.2 运行代价
- 选择率(Selectivity)
- 索引相关性(index correlation)
- 3.2.2.3 整体代价
- seq_page_cost和random_page_cost
- 3.2.3 排序
- 3.3 创建单表查询的计划树
- 3.3.1 预处理
- 3.3.2 找出代价最小的访问路径
- 3.3.2.1 例1
- 3.3.2.2 例2
- 3.3.3 创建计划树
- 3.3.3.1 例1
- 3.3.3.2 例2
- 3.4 执行器如何工作
- 临时文件
- 3.5 连接
- 3.5.1 嵌套循环连接(Nested Loop Join)
- 3.5.1.1 嵌套循环连接
- 3.5.1.2 物化嵌套循环连接
- 临时元组存储
- 3.5.1.3 索引嵌套循环连接
- 3.5.1.4 其他变体
- 3.5.2 归并连接(Merge Join)
- 3.5.2.1 归并连接
- 3.5.2.2 物化归并连接
- 3.5.2.3 其他变体
- 3.5.3 散列连接(Hash Join)
- 3.5.3.1 内存散列连接
- 3.5.3.2 带倾斜的混合散列连接
- 3.5.4 连接访问路径与连接节点
- 3.5.4.1 连接访问路径
- 3.5.4.2 连接节点
- 3.6 创建多表查询计划树
- 3.6.1 预处理
- 3.6.2 获取代价最小的路径
- 基因查询优化器
- 3.6.2.1 第一层的处理
- 3.6.2.2 第二层的处理
- 3.6.3 获取三表查询代价最小的路径
- 参考文献
查询处理是PostgreSQL中最为复杂的子系统。如PostgreSQL官方文档所述,PostgreSQL支持SQL2011标准中的大多数特性,查询处理子系统能够高效地处理这些SQL。本章概述了查询处理的流程,特别关注了查询优化的部分。
本章包括下列三个部分:
第一部分:3.1节
这一节会简单介绍PostgreSQL中查询处理的流程。
第二部分:3.2~3.4节
这一部分会描述获取单表查询上最优执行计划的步骤。3.2节讨论代价估计的过程,3.3节描述创建计划树的过程,3.4节将简要介绍执行器的工作过程。
第三部分:3.5~3.6节
这一部分会描述获取多表查询上最优执行计划的步骤。3.5节介绍了三种连接算法:嵌套循环连接(Nested Loop Join),归并连接(Merge Join) ,散列连接(Hash Join)。3.6节将介绍为多表查询创建计划树的过程。
PostgreSQL支持三种技术上很有趣,而且也很实用的功能:外部数据包装(Foreign Data Wrapper, FDW),并行查询,以及版本11即将支持的JIT编译。前两者将在第4章中描述,JIT编译超出范围本书的范围,详见官方文档。
3.1 概览
尽管PostgreSQL在9.6版本后有了基于多个后台工作进程的并行查询,但大体上来讲,还是每个连接对应一个后端进程。后端进程由五个子系统组成,如下所示:
解析器(Parser)
解析器根据SQL语句生成一颗语法解析树(parse tree) 。
分析器(Analyzer)
分析器对语法解析树进行语义分析,生成一颗查询树(query tree)。
重写器(Rewriter)
重写器按照规则系统中存在的规则,对查询树进行改写。
计划器(Planner)
计划器基于查询树,生成一颗执行效率最高的计划树(plan tree)。
执行器(Executor)
执行器按照计划树中的顺序访问表和索引,执行相应查询。
图3.1 查询处理
本节将概述这些子系统。计划器和执行器很复杂,后面的章节会对这些函数的细节进行描述。
PostgreSQL的查询处理在官方文档中有详细的描述
3.1.1 解析器(Parser)
解析器基于SQL语句的文本,生成一颗后续子系统可以理解的语法解析树。下面是一个具体的例子。
考虑以下查询:
1 | testdb=# SELECT id, data FROM tbl_a WHERE id < 300 ORDER BY data; |
语法解析树的根节点是一个定义在parsenodes.h
中的SelectStmt
数据结构。图3.2(a)展示了一个查询,而图3.2(b)则是该查询对应的语法解析树。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 | typedef struct SelectStmt { NodeTag type; /* 这些字段只会在SelectStmts“叶节点”中使用 */ List *distinctClause; /* NULL, DISTINCT ON表达式列表, 或 对所有的(SELECT DISTINCT)为lcons(NIL,NIL) */ IntoClause *intoClause; /* SELECT INTO 的目标 */ List *targetList; /* 结果目标列表 (ResTarget) */ List *fromClause; /* FROM 子句 */ Node *whereClause; /* WHERE 限定条件 */ List *groupClause; /* GROUP BY 子句 */ Node *havingClause; /* HAVING 条件表达式 */ List *windowClause; /* WINDOW window_name AS (...), ... */ /* 在一个表示值列表的叶节点中,上面的字段全都为空,而这个字段会被设置。 * 注意这个子列表中的元素仅仅是表达式,没有ResTarget的修饰,还需要注意列表元素可能为 * DEFAULT (表示一个 SetToDefault 节点),而无论值列表的上下文。 * 由分析阶段决定否合法并拒绝。 */ List *valuesLists; /* 未转换的表达式列表 */ /* 这些字段会同时在SelectStmts叶节点与SelectStmts上层节点中使用 */ List *sortClause; /* 排序子句 (排序依据的列表) */ Node *limitOffset; /* 需要跳过的元组数目 */ Node *limitCount; /* 需要返回的元组数目 */ List *lockingClause; /* FOR UPDATE (锁子句的列表) */ WithClause *withClause; /* WITH 子句 */ /* 这些字段只会在上层的 SelectStmts 中出现 */ SetOperation op; /* set 操作的类型 */ bool all; /* 是否指明了 ALL 选项? */ struct SelectStmt *larg; /* 左子节点 */ struct SelectStmt *rarg; /* 右子节点 */ } SelectStmt; |
图3.2. 语法解析树的例子
SELECT
查询中的元素和语法解析树中的元素有着对应关系。比如,(1)是目标列表中的一个元素,与目标表的'id'
列相对应,(4)是一个WHERE
子句,诸如此类。
当解析器生成语法分析树时只会检查语法,只有当查询中出现语法错误时才会返回错误。解析器并不会检查输入查询的语义,举个例子,如果查询中包含一个不存在的表名,解析器并不会报错,语义检查由分析器负责。
3.1.2 分析器(Analyzer)
分析器对解析器产出的语法解析树(parse tree)进行语义分析,并产出一颗查询树(query tree)。
查询树的根节点是parsenode.h
中定义的Query
数据结构,这个结构包含着对应查询的元数据,比如命令的类型(SELECT/INSERT
等),还包括了一些叶子节点,叶子节点由列表或树组成,包含了特定子句相应的数据。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 | /* * Query - * 解析与分析过程会将所有的语句转换为一颗查询树,供重写器与计划器用于进一步的处理。 * 功能语句(即不可优化的语句)会设置utilityStmt字段,而Query结构本身基本上是空的。 * DECLARE CURSOR 是一个特例:它的形式与SELECT类似,但原始的DeclareCursorStmt会 * 被放在 utilityStmt 字段中。 * 计划过程会将查询树转换为一颗计划树,计划树的根节点是一个PlannedStmt结构 * 执行器不会用到查询树结构 */ typedef struct Query { NodeTag type; CmdType commandType; /* select|insert|update|delete|utility */ QuerySource querySource; /* 我来自哪里? */ uint32 queryId; /* 查询标识符 (可由插件配置) */ bool canSetTag; /* 我设置了命令结果标签吗? */ Node *utilityStmt; /* 如果这是一条DECLARE CURSOR或不可优化的语句 */ int resultRelation; /* 对增删改语句而言是目标关系的索引; SELECT为0 */ bool hasAggs; /* 是否在目标列表或having表达式中指定了聚合函数 */ bool hasWindowFuncs; /* tlist是否包含窗口函数 */ bool hasSubLinks; /* 是否包含子查询SubLink */ bool hasDistinctOn; /* 是否包含来自DISTINCT ON的distinct子句 */ bool hasRecursive; /* 是否制定了WITH RECURSIVE */ bool hasModifyingCTE; /* 是否在WITH子句中包含了INSERT/UPDATE/DELETE */ bool hasForUpdate; /* 是否指定了FOR [KEY] UPDATE/SHARE*/ bool hasRowSecurity; /* 是否应用了行安全策略 */ List *cteList; /* CTE列表 */ List *rtable; /* 范围表项目列表 */ FromExpr *jointree; /* 表连接树 (FROM 与 WHERE 子句) */ List *targetList; /* 目标列表 (TargetEntry的列表) */ List *withCheckOptions; /* WithCheckOption的列表 */ OnConflictExpr *onConflict; /* ON CONFLICT DO [NOTHING | UPDATE] */ List *returningList; /* 返回值列表(TargetEntry的列表) */ List *groupClause; /* SortGroupClause的列表 */ List *groupingSets; /* 如果有,GroupingSet的列表 */ Node *havingQual; /* 分组的Having条件列表 */ List *windowClause; /* 窗口子句列表 */ List *distinctClause; /* SortGroupClause列表 */ List *sortClause; /* SortGroupClause列表 */ Node *limitOffset; /* Offset跳过元组数目 (int8 表达式) */ Node *limitCount; /* Limit返回元组数目 (int8 表达式) */ List *rowMarks; /* RowMarkClause列表 */ Node *setOperations; /* 如果是UNION/INTERSECT/EXCEPT的顶层查询, 则为集合操作列表 */ List *constraintDeps; /* 确认查询语义是否合法时,所依赖约束对象的OID列表 */ } Query; |
图3.3 查询树一例
简要介绍一下上图中的查询树:
targetlist
是查询结果中列(Column)的列表。在本例中该列表包含两列:id
和data
。如果在输入的查询树中使用了*
(星号),那么分析器会将其显式替换为所有具体的列。- 范围表
rtable
是该查询所用到关系的列表。本例中该变量包含了表tbl_a
的信息,如该表的表名与oid
。 - 连接树
jointree
存储着FROM
和WHERE
子句的相关信息。 - 排序子句
sortClause
是SortGroupClause
结构体的列表。
官方文档描述了查询树的细节。
3.1.3 重写器(Rewriter)
PostgreSQL的规则系统正是基于重写器实现的;当需要时,重写器会根据存储在pg_rules
中的规则对查询树进行转换。规则系统本身也是一个很有趣的系统,不过本章略去了关于规则系统和重写器的描述,以免内容过于冗长。
视图
在PostgreSQL中,视图是基于规则系统实现的。当使用
CREATE VIEW
命令定义一个视图时,PostgreSQL就会创建相应的规则,并存储到系统目录中。假设下面的视图已经被定义,而
pg_rule
中也存储了相应的规则。
123 sampledb=# CREATE VIEW employees_listsampledb-# AS SELECT e.id, e.name, d.name AS departmentsampledb-# FROM employees AS e, departments AS d WHERE e.department_id = d.id;当执行一个包含该视图的查询,解析器会创建一颗如图3.4(a)所示的语法解析树。
1 sampledb=# SELECT * FROM employees_list;在该阶段,重写器会基于
pg_rules
中存储的视图规则将rangetable
节点重写为一颗查询子树,与子查询相对应。图3.4 重写阶段一例
因为PostgreSQL使用这种机制实现视图,直到9.2版本,视图都是不能更新的。虽然9.3版本后可以对视图进行更新,但对视图的更新仍然存在很多限制,具体细节请参考官方文档。
3.1.4 计划器与执行器
计划器从重写器获取一颗查询树(query tree),基于查询树生成一颗能被执行器高效执行的(查询)计划树(plan tree)。
在PostgreSQL中,计划器是完全基于代价估计(cost-based)的;它不支持基于规则的优化与提示(hint)。计划器是RDBMS中最为复杂的部分,因此本章的后续内容会对计划器做一个概述。
pg_hint_plan
PostgreSQL不支持SQL中的提示(hint),并且永远也不会去支持。如果你想在查询中使用提示,可以考虑使用
pg_hint_plan
扩展,细节请参考官方站点。
与其他RDBMS类似,PostgreSQL中的EXPLAIN
命令会显示命令的计划树。下面给出了一个具体的例子。
1 2 3 4 5 6 7 8 | testdb=# EXPLAIN SELECT * FROM tbl_a WHERE id < 300 ORDER BY data; QUERY PLAN --------------------------------------------------------------- Sort (cost=182.34..183.09 rows=300 width=8) Sort Key: data -> Seq Scan on tbl_a (cost=0.00..170.00 rows=300 width=8) Filter: (id < 300) (4 rows) |
图3.5展示了结果相应的计划树。
图3.5 一个简单的计划树以及其与EXPLAIN命令的关系
计划树由许多称为计划节点(plan node)的元素组成,这些节点挂在PlannedStmt
结构对应的计划树上。这些元素的定义在plannodes.h
中,第3.3.3节与第3.5.4.2会解释相关细节。
每个计划节点都包含着执行器进行处理所必需的信息,在单表查询的场景中,执行器会按照从终端节点往根节点的顺序依次处理这些节点。
比如图3.5中的计划树就是一个列表,包含一个排序节点和一个顺序扫描节点;因而执行器会首先对表tbl_a
执行顺序扫描,并对获取的结果进行排序。
执行器会通过第8章将介绍的缓冲区管理器来访问数据库集簇的表和索引。当处理一个查询时,执行器会使用预先分配的内存空间,比如temp_buffers
和work_mem
,必要时还会创建临时文件。
图3.6 执行器,缓冲管理器,临时文件之间的关系
除此之外,当访问元组的时候,PostgreSQL还会使用并发控制机制来维护运行中事务的一致性和隔离性。第五章介绍了并发控制机制。
3.2 单表查询的代价估计
PostgreSQL的查询优化是基于代价(Cost)的。代价是一个无量纲的值,它并不是一种绝对的性能指标,但可以作为比较各种操作代价时的相对性能指标。
costsize.c
中的函数用于估算各种操作的代价。所有被执行器执行的操作都有着相应的代价函数。例如,函数cost_seqscan()
和 cost_index()
分别用于估算顺序扫描和索引扫描的代价。
在PostgreSQL中有三种代价:启动(start-up) , 运行(run)和总和(total)。总代价是启动代价和运行代价的和;因此只有启动代价和运行代价是单独估计的。
- 启动代价(start-up):在读取到第一条元组前花费的代价,比如索引扫描节点的启动代价就是读取目标表的索引页,取到第一个元组的代价
- 运行代价(run): 获取全部元组的代价
- 总代价(total):前两者之和
EXPLAIN
命令显示了每个操作的启动代价和总代价,下面是一个简单的例子:
1 2 3 4 5 | testdb=# EXPLAIN SELECT * FROM tbl; QUERY PLAN --------------------------------------------------------- Seq Scan on tbl (cost=0.00..145.00 rows=10000 width=8) (1 row) |
在第4行显示了顺序扫描的相关信息。代价部分包含了两个值:0.00和145.00。在本例中,启动代价和总代价分别为0.00和145.00。
在本节中,我们将详细介绍顺序扫描,索引扫描和排序操作的代价是如何估算的。
在接下来的内容中,我们使用下面这个表及其索引作为例子。
1 2 3 4 5 6 7 8 9 10 11 12 13 | testdb=# CREATE TABLE tbl (id int PRIMARY KEY, data int); testdb=# CREATE INDEX tbl_data_idx ON tbl (data); testdb=# INSERT INTO tbl SELECT generate_series(1,10000),generate_series(1,10000); testdb=# ANALYZE; testdb=# \d tbl Table "public.tbl" Column | Type | Modifiers --------+---------+----------- id | integer | not null data | integer | Indexes: "tbl_pkey" PRIMARY KEY, btree (id) "tbl_data_idx" btree (data) |
3.2.1 顺序扫描
顺序扫描的代价是通过函数cost_seqscan()
估计的。本节将研究顺序扫描代价是如何估计的,以下面的查询为例:
1 | testdb=# SELECT * FROM tbl WHERE id < 8000; |
在顺序扫描中,启动代价等于0,而运行代价由以下公式定义: $$ \begin{align} \verb|run_cost| &= \verb|cpu_run_cost| + \verb|disk_run_cost | \ &= (\verb|cpu_tuple_cost| + \verb|cpu_operatorcost|) × N{\verb|tuple|} + \verb|seq_pagecost| × N{\verb|page|}, \end{align} $$ 其中seq_page_cost
,cpu_tuple_cost
和cpu_operator_cost
是在postgresql.conf 中配置的参数,默认值分别为1.0,0.01和0.0025。$N{\verb|tuple|}$ 和$N{\verb|page|}$ 分别是表中的元组总数与页面总数,这两个值可以使用以下查询获取。
1 2 3 4 5 | testdb=# SELECT relpages, reltuples FROM pg_class WHERE relname = 'tbl'; relpages | reltuples ----------+----------- 45 | 10000 (1 row) |
$$ \begin{equation}\tag{1} N_{\verb|tuple|}=10000 \end{equation} $$
$$ \begin{equation}\tag{2} N_{\verb|page|}=45 \end{equation} $$
因此: $$ \begin{align} \verb|run_cost| &= (0.01 + 0.0025) × 10000 + 1.0 × 45 = 170.0. \end{align} $$
最终: $$ \verb|total_cost| = 0.0 + 170.0 = 170.0 $$
作为验证,下面是该查询的EXPLAIN
结果:
1 2 3 4 5 6 | testdb=# EXPLAIN SELECT * FROM tbl WHERE id < 8000; QUERY PLAN -------------------------------------------------------- Seq Scan on tbl (cost=0.00..170.00 rows=8000 width=8) Filter: (id < 8000) (2 rows) |
在第4行中可以看到,启动代价和总代价分别是0.00和170.0,且预计全表扫描返回行数为8000条(元组)。
在第5行显示了一个顺序扫描的过滤器Filter:(id < 8000)
。更精确地说,它是一个表级过滤谓词(table level filter predicate)。注意这种类型的过滤器只会在读取所有元组的时候使用,它并不会减少需要扫描的表页面数量。
从优化运行代价的角度来看,PostgreSQL假设所有的物理页都是从存储介质中获取的;即,PostgreSQL不会考虑扫 描的页面是否来自共享缓冲区。
3.2.2 索引扫描
尽管PostgreSQL支持很多索引方法,比如B树,GiST,GIN和BRIN,不过索引扫描的代价估计都使用一个共用的代价函数:cost_index()
。
本节将研究索引扫描的代价是如何估计的,以下列查询为例。
1 | testdb=# SELECT id, data FROM tbl WHERE data < 240; |
在估计该查询的代价之前,下面的查询能获取$N{\verb|index|,\verb|page|}$和$N{\verb|index|,\verb|tuple|}$的值:
1 2 3 4 5 | testdb=# SELECT relpages, reltuples FROM pg_class WHERE relname = 'tbl_data_idx'; relpages | reltuples ----------+----------- 30 | 10000 (1 row) |
$$ \begin{equation}\tag{3} N_{\verb|index|,\verb|tuple|} = 10000 \end{equation} $$
$$ \begin{equation}\tag{4} N_{\verb|index|,\verb|page|} = 30 \end{equation} $$
3.2.2.1 启动代价
索引扫描的启动代价就是读取索引页以访问目标表的第一条元组的代价,由下面的公式定义: $$ \begin{equation} \verb| start-up_cost| = {\mathrm{ceil}(\log2 (N{\verb|index|,\verb|tuple|})) + (H_{\verb|index|} + 1) × 50} × \verb|cpu_operatorcost| \end{equation} $$ 其中$H{\verb|index|}$是索引树的高度。
在本例中,套用公式(3),$N{\verb|index,tuple|}$是10000;$H{\verb|index|}$是1;$\verb|cpu_operator_cost|$是0.0025(默认值)。因此 $$ \begin{equation}\tag{5} \verb|start-up_cost| = {\mathrm{ceil}(\log_2(10000)) + (1 + 1) × 50} × 0.0025 = 0.285 \end{equation} $$
3.2.2.2 运行代价
索引扫描的运行代价是表和索引的CPU代价与IO代价之和。 $$ \begin{align} \verb|run_cost| &= (\verb|index_cpu_cost| + \verb|table_cpu_cost|) + (\verb|index_io_cost| + \verb|table_io_cost|). \end{align} $$
前三个代价(即index_cpu_cost
,table_cpu_cost
和index_io_cost
)如下所示:
$$ \begin{align} \verb|index_cpucost| &= \verb|Selectivity| × N{\verb|index|,\verb|tuple|} × (\verb|cpu_index_tuple_cost| + \verb|qual_op_cost|) \ \verb|table_cpucost| &= \verb|Selectivity| × N{\verb|tuple|}× \verb|cpu_tuple_cost| \ \verb|index_iocost| &= \mathrm{ceil}(\verb|Selectivity| × N{\verb|index|,\verb|page|}) ×\verb|random_page_cost| \end{align} $$
以上公式中的cpu_index_tuple_cost
和random_page_cost
在postgresql.conf中配置(默认值分别为0.005和4.0)。$\verb|qual_op_cost|$粗略来说就是索引求值的代价,默认值是0.0025,这里不再展开。选择率(Selectivity)是一个0到1之间的浮点数,代表查询指定的MARKDOWN_HASH5105e0481cb9b1e1d0dd3e10bab1f1c0MARKDOWNHASH
子句在索引中搜索范围的比例。举个例子,$(\verb|Selectivity| × N{\verb|tuple|})$就是需要读取的表元组数量,$(\verb|Selectivity| × N_{\verb|index|,\verb|tuple|})$就是需要读取的索引元组数量,诸如此类。
选择率(Selectivity)
查询谓词的选择率是通过直方图界值(histogram_bounds)与高频值(Most Common Value, MCV)估计的,这些信息都存储在系统目录
pg_statistics
中,并可通过pg_stats
视图查询。这里通过一个具体的例子来简要介绍选择率的计算方法,细节可以参考官方文档。表中每一列的高频值都在
pg_stats
视图的most_common_vals
和most_common_freqs
中成对存储。
- 高频值(most_common_vals):该列上最常出现的取值列表
- 高频值频率(most_common_freqs):高频值相应出现频率的列表
下面是一个简单的例子。表
countries
有两列:一列country
存储国家名,一列continent
存储该国所属大洲。
123456789101112131415161718192021 testdb=# \d countriesTable "public.countries"Column | Type | Modifiers-----------+------+-----------country | text |continent | text |Indexes:"continent_idx" btree (continent)testdb=# SELECT continent, count(*) AS "number of countries",testdb-# (count(*)/(SELECT count(*) FROM countries)::real) AS "number of countries / all countries"testdb-# FROM countries GROUP BY continent ORDER BY "number of countries" DESC;continent | number of countries | number of countries / all countries---------------+---------------------+-------------------------------------Africa | 53 | 0.274611398963731Europe | 47 | 0.243523316062176Asia | 44 | 0.227979274611399North America | 23 | 0.119170984455959Oceania | 14 | 0.0725388601036269South America | 12 | 0.0621761658031088(6 rows)考虑下面的查询,该查询带有
WHERE
条件continent = 'Asia'
。
1 testdb=# SELECT * FROM countries WHERE continent = 'Asia';这时候,计划器使用
continent
列上的高频值来估计索引扫描的代价,列上的most_common_vals
与most_common_freqs
如下所示:
1234567 testdb=# \xExpanded display is on.testdb=# SELECT most_common_vals, most_common_freqs FROM pg_statstestdb-# WHERE tablename = 'countries' AND attname='continent';-[ RECORD 1 ]-----+-----------------------------------------------------------most_common_vals | {Africa,Europe,Asia,"North America",Oceania,"South America"}most_common_freqs | {0.274611,0.243523,0.227979,0.119171,0.0725389,0.0621762}与
most_common_vals
中Asia
值对应的most_common_freqs
为0.227979。因此0.227979会在估算中被用作选择率。如果高频值不可用,就会使用目标列上的直方图界值来估计代价。
- 直方图值(histogram_bounds)是一系列值,这些值将列上的取值划分为数量大致相同的若干个组。
下面是一个具体的例子。这是表
tbl
中data
列上的直方图界值;
123456789 testdb=# SELECT histogram_bounds FROM pg_stats WHERE tablename = 'tbl' AND attname = 'data';histogram_bounds------------------------------------------------------------------------------{1,100,200,300,400,500,600,700,800,900,1000,1100,1200,1300,1400,1500,1600,1700,1800,1900,2000,2100,2200,2300,2400,2500,2600,2700,2800,2900,3000,3100,3200,3300,3400,3500,3600,3700,3800,3900,4000,4100,4200,4300,4400,4500,4600,4700,4800,4900,5000,5100,5200,5300,5400,5500,5600,5700,5800,5900,6000,6100,6200,6300,6400,6500,6600,6700,6800,6900,7000,7100,7200,7300,7400,7500,7600,7700,7800,7900,8000,8100,8200,8300,8400,8500,8600,8700,8800,8900,9000,9100,9200,9300,9400,9500,9600,9700,9800,9900,10000}(1 row)默认情况下,直方图界值会将列上的取值划分入100个桶。图3.7展示了这些桶及其对应的直方图界值。桶从0开始编号,每个桶保存了(大致)相同数量的元组。直方图界值就是相应桶的边界。比如,直方图界值的第0个值是1,意即这是
bucket_0
中的最小值。第1个值是100,意即bucket_1
中的最小值是100,等等。本人提供Oracle(OCP、OCM)、MySQL(OCP)、PostgreSQL(PGCA、PGCE、PGCM)等数据库的培训和考证业务,私聊QQ646634621或微信db_bao,谢谢!