PostgreSQL逻辑优化—这样搭建整体架构

一棵完成 transform 和 rewrite 操作的查询树是否是一棵***的查询树？如果不是，那么又该如何对该查询树进行优化？而优化所使用的策略正是本文要讨论的重点内容，而且优化部分也是整个查询引擎的难点。

创新互联坚持“要么做到，要么别承诺”的工作理念，服务领域包括：成都网站设计、网站建设、企业官网、英文网站、手机端网站、网站推广等服务，满足客户于互联网时代的芙蓉网站设计、移动媒体设计的需求，帮助企业找到有效的互联网解决方案。努力成为您成熟可靠的网络建设合作伙伴！

子链接（SubLink）如何优化？子查询（SubQuery）又如何处理？对表达式（Expression）如何进行优化？如何寻找***的查询计划（Cheapest Plan）？哪些因素会影响 JOIN 策略（Join Strategies）的选择，而这些策略又是什么？查询代价（Cost）又是如何估算的？何时需对查询计划进行物化（Plan Materialization）处理等一系列的问题。

在查询计划的优化过程中，对不同的语句类型有着不同的处理策略：

（1）对工具类语句（例如，DML、DDL 语句），不进行更进一步的优化处理。

（2）当语句为非工具语句时，PostgreSQL 使用 pg_plan_queries 对语句进行优化。

与前面一样，PostreSQL 也提供定制化优化引擎接口，我们可以使用自定义优化器 planner_hook，或者使用标准化优化器 standard_planner。

Pg_plan_queries 的函数原型如下所示。

逻辑优化——整体架构介绍

在未使用第三方提供的优化器时，PostgreSQL 将 planner 函数作为优化的入口函数，并由函数 subquery_planner 来完成具体的优化操作。从下图中的 Call Stack 我们可以看出 planner 与 subquery_planner 之间的调用关系。

函数以查询树作为输入参数，并以优化后语句作为返回值。

在 standard_planner 中，首先处理 “DECLARE CURSOR stmt” 形式的语句，即游标语句，并设置 tuple_fraction 值。那么 tuple_fraction 又是什么呢？

tuple_fraction 描述我们期望获取的元组的比例，0 代表我们需要获取所有的元组；当 tuple_factionÎ(0,1) 时，表明我们需要从满足条件的元组中取出 tuple_faction 这么多比例的元组；当 tuple_factionÎ [1,+¥ ) 时，表明我们将按照所指定的元组数进行检索，例如，LIMIT 语句中所指定的元组数。

完成对 tuple_faction 的设置后，进入后续优化流程，subquery_planner 的函数原型如下所示。

这里也许你也许会迷惑，为什么是 subquery_planner 呢？从名字上看该函数像是用来处理子查询，那么为什么用来作为整个查询语句优化的入口呢（Primary Entry Point）？

子查询语句作为查询语句的一部分，很大程度上与父查询具有相似的结构，同时两者在处理方式和方法上也存在着一定的相似性：子查询的处理流程可以在对其父查询的过程中使用。例如，本例中的子查询语句 SELECT sno FROM student WHERE student.classno = sub.classno，其处理方式与整个查询语句一样。因此，使用 subquery_planner 作为我们查询优化的入口，虽然从函数名上来看其似乎是用于子查询语句的处理。

由 gram.y 中给出的 SelectStmt 的定义可以看出，其中包括了诸如 WINDOWS、HAVING、ORDER BY、GROUP BY 等子句。那du么 subquery_planner 函数似乎也应该有相应于这些语句的优化处理。就这点而言，subquery_planner 与原始语法树到查询树的转换所采取的处理方式相似。根据上述分析，我们可给出如下所示的 subquery_planner 的函数原型。

按照上述给出的原型，只要完成假定的 process_xxx 函数，就可以实现对查询语法树的优化工作。是不是觉得很简单？当然不是，原理很简单，但是理论与实际还有一定的距离。

例如，如何处理查询中大量出现的子链接？如何对 d 算子执行 “下推”？如何选择索引？如何选择 JOIN 策略？这些都需要我们仔细处理。

PostgreSQL 给出的 subquery_planner 如下所示。

由 PostgreSQL 给出的实现可以看出，核心处理思想与我们讨论的相一致：依据类型对查询语句进行分类处理。

这里需要注意的一点就是查询计划的生成部分，PostgreSQL 将查询计划的生成也归入 subquery_planner 中，但为了方便问题的讨论，我们并未将查询计划的生成部分在 subquery_planner 中给出。我们将查询优化的主要步骤总结如下：

处理 CTE 表达式，ss_process_ctes；

上提子链接，pull_up_sublinks；

FROM 子句中的内联函数，集合操作，RETURN 及函数处理，inline_set_returning_ functions；

上提子查询，pull_up_subqueries；

UNION ALL 语句处理，flatten_simple_union_all；

处理 FOR UPDATE（row lock）情况，preprocess_rowmarks；

继承表的处理，expand_inherited_tables；

处理目标列（target list），preprocess_expression；

处理 withCheckOptions，preprocess_expression；

处理 RETURN 表达式，preprocess_expression；

处理条件语句 - qual，preprocess_qual_conditions；

处理 HAVING 子句，preprocess_qual_conditions；

处理 WINDOW 子句，preprocess_qual_conditions；

处理 LIMIT OFF 子句，preprocess_qual_conditions；

WHERE 和 HAVING 子句中的条件合并，如果存在能合并的 HAVING 子句则将其合并到 WHERE 条件中，否则保留在 HAVING 子句中； 

消除外连接（Outer Join）中的冗余部分，reduce_outer_joins；

生成查询计划，grouping_planner。 

本文标题：PostgreSQL逻辑优化—这样搭建整体架构
网站链接：http://www.shufengxianlan.com/qtweb/news41/62941.html

网站建设、网络推广公司-创新互联，是专注品牌与效果的网站制作，网络营销seo公司；服务项目有等

广告

声明：本网站发布的内容（图片、视频和文字）以用户投稿、用户转载内容为主，如果涉及侵权请尽快告知，我们将会在第一时间删除。文章观点不代表本网站立场，如需处理请联系客服。电话：028-86922220；邮箱：631063699@qq.com。内容未经允许不得转载，或转载时需注明来源： 创新互联