# 14.1.使用解释
PostgreSQL设计了一个查询计划对于它收到的每个查询。选择正确的计划来匹配查询结构和数据属性对于良好的性能是绝对关键的,因此系统包括一个复杂的计划者努力选择好的计划。你可以使用解释
命令查看计划器为任何查询创建的查询计划。计划阅读是一门需要一定经验才能掌握的艺术,但本节试图介绍基本知识。
本节中的示例来自回归测试数据库真空分析
,使用9.3开发源。如果您自己尝试这些示例,应该能够得到类似的结果,但是您的估计成本和行数可能会略有不同,因为分析
公司的统计数据是随机样本,而不是精确的,因为成本在某种程度上取决于平台。
这些例子使用解释
的默认“文本”输出格式,该格式紧凑,便于人们阅读。如果你想吃饭解释
的输出到程序进行进一步分析时,应使用其机器可读的输出格式之一(XML、JSON或YAML)。
# 14.1.1. 解释
基础
查询计划的结构是一棵树计划节点.树底部的节点是扫描节点:它们从表中返回原始行。对于不同的表访问方法,有不同类型的扫描节点:顺序扫描、索引扫描和位图索引扫描。还有非表行源,例如价值观
子句和集合返回函数从…起
,它们有自己的扫描节点类型。如果查询需要对原始行执行联接、聚合、排序或其他操作,则扫描节点上方会有其他节点来执行这些操作。同样,通常有不止一种可能的方法来执行这些操作,因此这里也可以出现不同的节点类型。输出解释
为计划树中的每个节点显示一行,显示基本节点类型加上计划员为执行该计划节点所做的成本估算。可能会显示从节点摘要行缩进的其他行,以显示节点的其他属性。第一行(最顶层节点的汇总行)包含计划的估计总执行成本;规划者试图将这个数字降到最低。
下面是一个简单的例子,只是为了说明输出是什么样子:
EXPLAIN SELECT * FROM tenk1;
QUERY PLAN
### 14.1.2. `EXPLAIN ANALYZE`
It is possible to check the accuracy of the planner's estimates by using `EXPLAIN`'s `ANALYZE` option. With this option, `EXPLAIN` actually executes the query, and then displays the true row counts and true run time accumulated within each plan node, along with the same estimates that a plain `EXPLAIN` shows. For example, we might get a result like this:
解释分析从tenk1 t1,tenk2 t2中选择*其中t1.unique1<10和t1.unique2=t2.独特的2;
QUERY PLAN
# 14.1.3.警告
有两种重要的方式可以通过解释分析
可能会偏离同一查询的正常执行。首先,由于没有向客户机发送输出行,因此不包括网络传输成本和I/O转换成本。第二,增加的测量开销解释分析
这可能非常重要,尤其是在速度较慢的机器上gettimeofday()
操作系统调用。你可以使用pg_测验_时机用于测量系统计时开销的工具。
解释
结果不应该外推到与你实际测试的情况有很大不同的情况;例如,不能假设玩具大小的桌子上的结果适用于大型桌子。规划师的成本估算不是线性的,因此它可能会为较大或较小的表选择不同的计划。一个极端的例子是,在只占用一个磁盘页的表上,无论索引是否可用,几乎总是会得到一个顺序扫描计划。planner意识到,在任何情况下,都需要读取一个磁盘页面来处理表,因此花费额外的页面读取来查看索引没有任何价值。(我们在电视上看到了这种情况。)多边形
上面的例子。)
在某些情况下,实际值和估计值并不匹配,但没有什么是真正错误的。其中一种情况是,当计划节点的执行被限度
或者类似的效果。例如,在限度
我们以前使用的查询,
EXPLAIN ANALYZE SELECT * FROM tenk1 WHERE unique1 < 100 AND unique2 > 9000 LIMIT 2;
QUERY PLAN