|
|
51CTO旗下网站
|
|
移动端

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

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

作者:佚名来源:ITPUB|2017-12-12 14:26

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。 

【编辑推荐】

  1. 12 月全球数据库排名:PostgreSQL 稳步上升
  2. 双11超级工程—阿里巴巴数据库技术架构演进
  3. 连续三月涨势明显,PostgreSQL 将崛起超越Oracle?!
  4. 多位大佬大胆预测:Hadoop将死,图数据库成为新趋势!
  5. Go在酷狗数据库中间件的应用
【责任编辑:庞桂玉 TEL:(010)68476606】

点赞 0
分享:
大家都在看
猜你喜欢

读 书 +更多

Visual C++编程从基础到实践

Visual C++ 6.0是Microsoft公司的Visual Studio开发组件中最强大的编程工具,利用它可以开发出高性能的应用程序。本书由浅入深,从基础到实...

订阅51CTO邮刊

点击这里查看样刊

订阅51CTO邮刊