| PostgreSQL 9.3.1 中文手册 | ||||
|---|---|---|---|---|
| 上一页 | 上一级 | 章 46. PostgreSQL内部概述 | 下一页 | |
规划器/优化器的任务是创建一个最优的执行规划。 一个特定的 SQL 查询(因此也就是一个查询树)实际上可以以多种不同的方式执行， 每种都生成相同的结果集。如果可能，查询优化器将检查每个可能的执行规划， 最终选择认为运行最快的执行规划。
注意: 有些情况下，检查一个查询所有可能的执行方式会花去很多时间和内存空间。 特别是执行的查询涉及大量连接操作的时候。 为了在合理的时间里选择一个合理的(而不是最优的)查询计划。PostgreSQL 当连接操作的数量超过一个阈值(参阅 geqo_threshold)时使用 基因查询优化器(参阅第 53 章)。
规划器的搜索过程实际上是与叫做paths的数据结构一起结合运转的， 这个数据结构是查询规划的一个精简版本，它只包括规划器用来决策所必须的信息。 在找到代价最小的路径之后，就生成一个完整的规划树传递给执行器， 它有足够的详细信息，表示需要执行的计划，执行器可以读懂并运行之。在本章剩余部分， 将忽略路径和规划之间的区别。
规划器/优化器开始于为查询中出现的每个关系(表)生成规划，这些规划用于对这些关系进行扫描， 每个关系上可能的规划是由其有哪些可用的索引决定的。对一个关系总是可以对其进行顺序扫描， 所以总是会创建只使用顺序扫描的规划。假设一个关系上定义着一个索引(例如 B-tree 索引)， 并且一条查询包含约束relation.attribute OPR constant。 如果relation.attribute碰巧匹配 B-tree 索引的关键字并且OPR 又是索引操作符类中的一个操作符， 那么将会创建另一个使用 B-tree 索引扫描该关系的规划。如果还有别的索引， 而且查询里面的约束又和那个索引的关键字匹配，则还会生成更多的规划。如果索引的排序与查询的ORDER BY子句（如果有）相匹配，或者排序可能有益于将来进行归并连接（见下），也会生成索引扫描规划。
如果查询需要连接两个或者更多的关系，在所有的对单一关系的扫描可行的规划被发现后， 连接各个关系的规划就要被考虑了。有三种可能的连接策略：
嵌套循环连接：对左边的关系里面找到的每一行都对右边关系进行一次扫描。 这个策略容易实现，但是可能会很耗费时间。（但是，如果右边的关系可以用索引扫描， 那么这个可能就是个好策略。可以使用左边关系中当前行的值作为对右边关系进行索引扫描的键。）
归并连接：在连接开始之前，每个关系都对连接字段进行排序。 然后对两个关系并发扫描，匹配的行就组合起来形成连接行。这种连接更有吸引力， 因为每个关系都只用扫描一次。要求的排序步骤可以通过明确的排序步骤， 或者是使用连接键字上的索引按照恰当的顺序对关系进行扫描。
Hash 连接：首先扫描右边的关系， 并用连接的字段作为散列键字加载进入一个 Hash 表，然后扫描左边的关系， 并将找到的每行用作散列键字来以定位表里匹配的行。
如果查询中的关系多于两个，最后的结果必须通过一个连接步骤树建立， 每个步骤有两个输入。规划器检查不同的、可能的连接顺序，找出开销最小的。
如果查询使用少于geqo_threshold的关系， 会使用一个近乎穷举的搜索方法查找最好的连接顺序。规划器优先考虑为存在连接子句的任意两个关系进行连接， 这些连接子句在WHERE约束条件（例如，存在像 where rel1.attr1=rel2.attr2这样的约束）。 没有连接子句的连接对只有在没有别的选择的时候才考虑，也就是说， 一个关系没有和任何其它关系有连接子句可用。规划器为每个连接对生成所有可能的规划， 并且那个（预计是）最经济的规划将被选择。
当连接数超出geqo_threshold时，连接顺序被认为是由启发式方法决定的， 如第 53 章所描述。否则，流程是相同的。
最终完成的规划树由三部分内容组成：对基础关系的顺序或索引扫描节点，嵌套循环、归并或Hash连接节点以及一些必须的辅助节点，比如排序节点和聚合函数计算节点。 这些规划节点类型中，大多数都可以做选择 (抛弃那些不符合指定布尔条件的行)和投影 (基于给出的字段数值计算一个派生出的字段集， 也就是在需要时计算标量表达式)。规划器的一个责任是从WHERE 子句中附加选择条件以及为规划树最合适的节点计算所需要的输出表达式。