Chapter 2. PostgreSQL 内部概貌

Table of Contents
2.1. 查询经过的路径
2.2. 联接是如何建立起来的
2.3. 分析器阶段
2.3.1. 分析器
2.3.2. 转换处理
2.4. PostgreSQL 规则系统
2.5. 规划器/优化器
2.5.1. 生成可能的规划
2.5.2. 规划的数据结构
2.6. 执行器

作者: 本章最初是 Enhancement of the ANSI SQL Implementation of PostgreSQL的一部分, 它是 Stefan Simkovics 在维也纳理工大学写的硕士论文, 是由 O.Univ.Prof.Dr. Georg Gottlob和Univ.Ass. Mag. Katrin Seyr 指导的。

本章给出了 PostgreSQL 后端服务器的内部情况的一个概貌。 在阅读完毕下面的章节后,你应该对查询是如何处理的有一个概念了。 不过别指望我们在这里有详细的描述(我想,要对 PostgreSQL 里面所有的数据结构和函数都做这样的详细描 述可能要超过 1000 页的内容!)。 本章只是试图帮助我们了解在后端里面从收到查询 到发出结果之间通常的控制和数据的流动。

2.1. 查询经过的路径

下面是一个简短的描述一个查询从开始到得到结果要经过的阶段。

  1. 首先必须先建立起从应用程序到 PostgreSQL 服务器的联接。应用程序向服务器发送查询然后接收从服务器返回的结果。

  2. 分析阶段(parser stage) 检查从应用程序(客户端)发送过来的查询, 核对语法并创建一个 查询树(query tree)

  3. 重写系统(rewrite system) 接收分析阶段来的查询树 且搜索任意应用到查询树上的 规则(rules) (存储在 系统表里)并根据给出的 规则体(rule bodies) 进行转换。 我们在 视图(views) 的实现里给出了重写系统的一个应用。

    当一个查询访问一个视图时(也就是说,一个 虚拟表(virtual table) ),重写系统改写用户的查询, 使之成为一个访问带有 视图定义(view definition)基本表(base tables)的查询。

  4. 规划器/优化器(planner/optimizer) 接收(改写的)查询树然后创建一个 查询规划(queryplan),这个查询规划是 执行器(executor)的输入。

    它(规划器/优化器)首先创建所有得出相同结果的可能的 路径(paths) 。例如,如果待扫描的关系上有一个索引,那么扫描的路径就有两个。 一个可能是简单的顺序查找,而另一个可能就是使用索引的那个。 下一步是计算出每个索引执行的开销,并且选择和返回开销最少的那个。

  5. 执行器递归地走过 规划树(plan tree) 并且在这个过程中检索规划所代表的元组。 执行器在对关系进行扫描时使用 存储系统(storage system) ,进行 排序(sorts)连接(joins), 计算 条件(qualifications) 并且最终交回生成的元组。

在随后的章节里,我们将对上面的每一个步骤进行更详细的讨论, 以便让我们对 PostgreSQL的内部控制和数据结构有一个更准确的理解。