postgres query plan

PostgreSQL数据库针对它收到的每一个sql查询都会设计一个query plan-查询计划。要想拥有良好的查询性能performance， 选择正确的query计划来匹配查询的结构和数据本身的特性绝对是至关重要的，因此postgres数据库系统有一个复杂的计划器planner用来为sql查询选择好的query plan。 我们可以使用 EXPLAIN 命令查看规划器为任何查询创建的查询计划。

query plan查询计划的结构是计划节点树plan node。 树底层的节点是数据库表扫描节点：它们从数据库表中返回数据的原始行。 不同的表访问方法有不同类型的扫描节点：顺序扫描sequential scan、index scan索引扫描和位图索引扫描bitmap scan。 如果查询需要对原始行进行join、aggregation聚合、排序或其他操作，那么在扫描节点之上会有额外的节点来执行这些操作。 同样，通常有不止一种可能的方法来执行这些操作，因此这里也可能出现不同的节点类型。 EXPLAIN 的输出当中对计划树中的每个节点都有一行，显示基本节点类型以及计划器为执行该计划节点所做的成本估计。 第一行（最上面的节点）是计划的估计总执行成本； sql规划寻求最小化的正是这个数字。

下面是一个例子:

EXPLAIN 生成的query plan中有几个数字，他们的意思是（从左到右）：

•  估计启动成本（输出扫描开始前花费的时间，例如在排序节点中进行排序的时间）
• 估计总成本（如果所有行都被检索时的花费，当然也有可能不会检索所有行带有 LIMIT 子句的查询将停止支付限制计划节点的输入节点的总成本）
• 此执行计划节点输出的估计行数（仅当执行完成时）
• 此执行计划节点输出的行的估计平均宽度（以字节为单位）

执行成本以由计划者的成本参数确定的任意单位进行衡量。 传统的做法是以磁盘页面获取为单位来衡量成本； 也就是说，seq_page_cost 通常设置为 1.0，而其他成本参数则相对于此设置。 

需要注意的是，上层节点的成本包括其所有子节点的成本。 同样重要的是要意识到成本只反映了计划者关心的事情。 特别是，成本不考虑将结果行传输到客户端所花费的时间，这可能是实际经过时间的一个重要因素； 但是计划者忽略了它，因为它不能通过改变计划来改变它。 （我们相信，每个正确的计划都会输出相同的行集。）

行值有点棘手，因为它不是计划节点处理或扫描的行数。 它通常较小，反映了在节点上应用的任何 WHERE 子句条件的估计选择性。 理想情况下，顶级行估计将近似于查询实际返回、更新或删除的行数。

回到我们的例子：

EXPLAIN SELECT * FROM tenk1;

                         QUERY PLAN
-------------------------------------------------------------
 Seq Scan on tenk1  (cost=0.00..458.00 rows=10000 width=244)

这很简单。 如果你这样做：

SELECT relpages, reltuples FROM pg_class WHERE relname = 'tenk1';

你会发现tenk1有358个磁盘页和10000行。 估计成本计算为（读取的磁盘页数 * seq_page_cost）+（扫描的行数 * cpu_tuple_cost&#x