话说查询“selectcname, comp from test1, test2 where test1.id=test2.id;” 发送到服务器端,走查询分支exec_simple_query,先调用start_xact_command初始化了事务管理相关对象和资源,接着调用pg_parse_query,通过Lex和Yacc对传入SQL语句进行词法语法解析,生成解析树。下来调用GetTransactionSnapshot方法做内存快照,然后调用pg_analyze_and_rewrite方法,进行语义分析把parsetree转换成querytree,然后对该querytree进行重写。接着调用pg_plan_queries方法,根据querytree做查询规划,生成查询计划树plantree。
1
下面是对querytree进行优化并生成plantree的调用序列图。
Postgres服务进程简查之查询规划调用序列图
上图红色方框中显示了pg_plan_queries方法对querytree做查询规划,生成查询计划树plantree的方法调用过程,大致上处理步骤是提升子连接和子查询、生成最优查询路径、生成执行计划。
在subquery_planner方法里都有方法pull_up_sublinks提升子连接,调用方法pull_up_subqueries提升子查询,目的是尽量合并父查询和子查询中的WHERE子句里的条件,尽量在做最耗费时间的表连接操作之前,先用约束条件把涉及到的元组数目缩到最小。接着处理表达式等,都是和前面同样的目的。
还有其中的方法inline_set_returning_functions内联返回函数、方法preprocess_rowmarks预处理行标记、方法expand_inherited_tables扩展集成表、方法preprocess_expression预处理表达式、方法reduce_outer_joins尽量减少外连接。
接着调用方法grouping_planner做规划处理,规划处理主要是生成路径,路径就是告诉执行器如何取到要操作的元组,这些元组可以来自一个表,也可以来自多个表,对于多个表,是按两两逐个连接完成,即转化成多个两表连接查询。举个例子,如一个查询涉及三个表A、B、C的连接,处理时可以先A、B连接生成结果D,再D、C连接得到目标结果集。这样连接的顺序就有多种,就产生了多个路径。方法query_planner生成了这些路径。然后评估代价,找出最优路径,把和最优路径对应的执行计划树plantree返回。Pg里面的代价估算采用基于成本的代价估算,本节后面会简单讨论一下这个估算方法。
这个过程涉及连接算法(Hash Join、Nested Loop、Merge
Join)、扫描算法(Seq Scan、Index Scan、Bitmap
Scan)、分组算法(HashAggregate、GroupAggregate)、排序算法等算法的选择。
这部分内容涉及到结构和处理及代码量比上节只多不少,在这就不列举了,有兴趣的根据方法调用流程图看源码吧,下面给出处理完的结果plantree结构图。
例子里查询语句对应的plantree结构图
把这个例子再重复一下:
create table test1 (ID numeric(10), cnamevarchar(30));
create table test2 (ID numeric(10), compvarchar(30));
select cname,comp from test1,test2 wheretest1.id=test2.id;
上面的图《例子里查询语句对应的plantree结构图》就是SQL语句“select
cname,comp from test1,test2 where test1.id=test2.id”在pg里产生的plantree。
pg输出的querytree如下:
2011-11-23 06:57:39 HKT LOG:
plan:
2011-11-23 06:57:39 HKT DETAIL:
{PLANNEDSTMT
:commandType 1
:hasReturning false
:hasModifyingCTE false
:canSetTag true
:transientPlan false
:planTree
{HASHJOIN
:startup_cost 24.63
:total_cost 116.69
:plan_rows 2113
:plan_width 156
:targetlist (
{TARGETENTRY
:expr
{VAR
:varno 65001
:varattno 2
:vartype 1043
:vartypmod 34
:varcollid 100
:varlevelsup 0
:varnoold 1
:varoattno 2
:location 7
}
:resno 1
:resname cname
:ressortgroupref 0
:resorigtbl 16394
:resorigcol 2
:resjunk false
}
{TARGETENTRY
:expr
{VAR
:varno 65000
:varattno 1
:vartype 1043
:vartypmod 34
:varcollid 100
:varlevelsup 0
:varnoold 2
:varoattno 2
:location 13
}
:resno 2
:resname comp
:ressortgroupref 0
:resorigtbl 16397
:resorigcol 2
:resjunk false
}
)
:qual <>
:lefttree
{SEQSCAN
:startup_cost 0.00
:total_cost 16.50
:plan_rows 650
:plan_width 94
:targetlist (
{TARGETENTRY
:expr
{VAR
:varno 1
:varattno 1
:vartype 1700
:vartypmod 655364
:varcollid 0
:varlevelsup 0
:varnoold 1
:varoattno 1
:location -1
}
:resno 1
:resname <>
:ressortgroupref 0
:resorigtbl 0
:resorigcol 0
:resjunk false
}
{TARGETENTRY
:expr
{VAR
:varno 1
:varattno 2
:vartype 1043
:vartypmod 34
:varcollid 100
:varlevelsup 0
:varnoold 1
:varoattno 2
:location -1
}
:resno 2
:resname <>
:ressortgroupref 0
:resorigtbl 0
:resorigcol 0
:resjunk false
}
)
:qual <>
:lefttree <>
:righttree <>
:initPlan <>
:extParam (b)
:allParam (b)
:scanrelid 1
}
:righttree
{HASH
:startup_cost 16.50
:total_cost 16.50
:plan_rows 650
:plan_width 94
:targetlist (
{TARGETENTRY
:expr
{VAR
:varno 65001
:varattno 1
:vartype 1043
:vartypmod 34
:varcollid 100
:varlevelsup 0
:varnoold 2
:varoattno 2
:location -1
}
:resno 1
:resname <>
:ressortgroupref 0
:resorigtbl 0
:resorigcol 0
:resjunk false
}
{TARGETENTRY
:expr
{VAR
:varno 65001
:varattno 2
:vartype 1700
:vartypmod 655364
:varcollid 0
:varlevelsup 0
:varnoold 2
:varoattno 1
:location -1
}
:resno 2
:resname <>
:ressortgroupref 0
:resorigtbl 0
:resorigcol 0
:resjunk false
}
)
:qual <>
:lefttree
{SEQSCAN
:startup_cost 0.00
:total_cost 16.50
:plan_rows 650
:plan_width 94
:targetlist (
{TARGETENTRY
:expr
{VAR
:varno 2
:varattno 2
:vartype 1043
:vartypmod 34
:varcollid 100
:varlevelsup 0
:varnoold 2
:varoattno 2
:location 13
}
:resno 1
:resname <>
:ressortgroupref 0
:resorigtbl 0
:resorigcol 0
:resjunk false
}
{TARGETENTRY
:expr
{VAR
:varno 2
:varattno 1
:vartype 1700
:vartypmod 655364
:varcollid 0
:varlevelsup 0
:varnoold 2
:varoattno 1
:location 50
}
:resno 2
:resname <>
:ressortgroupref 0
:resorigtbl 0
:resorigcol 0
:resjunk false
}
)
:qual <>
:lefttree <>
:righttree <>
:initPlan <>
:extParam (b)
:allParam (b)
:scanrelid 2
}
:righttree <>
:initPlan <>
:extParam (b)
:allParam (b)
:skewTable 16394
:skewColumn 1
:skewInherit false
:skewColType 1700
:skewColTypmod 655364
}
:initPlan <>
:extParam (b)
:allParam (b)
:jointype 0
:joinqual <>
:hashclauses (
{OPEXPR
:opno 1752
:opfuncid 1718
:opresulttype 16
:opretset false
:opcollid 0
:inputcollid 0
:args (
{VAR
:varno 65001
:varattno 1
:vartype 1700
:vartypmod 655364
:varcollid 0
:varlevelsup 0
:varnoold 1
:varoattno 1
:location 41
}
{VAR
:varno 65000
:varattno 2
:vartype 1700
:vartypmod 655364
:varcollid 0
:varlevelsup 0
:varnoold 2
:varoattno 1
:location 50
}
)
:location -1
}
)
}
:rtable (
{RTE
:alias <>
:eref
{ALIAS
:aliasname test1
:colnames ("id""cname")
}
:rtekind 0
:relid 16394
:relkind r
:inh false
:inFromCl true
:requiredPerms 2
:checkAsUser 0
:selectedCols (b 9 10)
:modifiedCols (b)
}
{RTE
:alias <>
:eref
{ALIAS
:aliasname test2
:colnames ("id""comp")
}
:rtekind 0
:relid 16397
:relkind r
:inh false
:inFromCl true
:requiredPerms 2
:checkAsUser 0
:selectedCols (b 9 10)
:modifiedCols (b)
}
)
:resultRelations <>
:utilityStmt <>
:intoClause <>
:subplans <>
:rewindPlanIDs (b)
:rowMarks <>
:relationOids (o 16394 16397)
:invalItems <>
:nParamExec 0
}
2
规划器为每个SQL的不同执行计划进行基于成本的代价估算,查询的总代价包括读取数据的IO代价加上各种操作的代价之和,IO代价包括顺序读取数据或索引页(seq_scan_cost)和随机读取数据页(random_scan_cost)的代价,操作代价包括处理表元组(cpu_tuple_cost)、处理比较操作(cpu_operator_cost)和处理索引元组(cpu_index_tuple_cost),因此,如果在一个表上做全表顺序扫描并执行过滤,其代价是:
Cost = seq_scan_cost*relpages + cpu_tuple_cost*reltuples +cpu_operator_cost*reltuples
其中relpages、reltuples是系统表pg_class里的字段,seq_scan_cost、cpu_tuple_cost、cpu_operator_cost是影响成本计算的参数,这些参数包括cpu_index_tuple_cost
(0.005)、cpu_operator_cost (0.0025)、cpu_tuple_cost (0.01)、random_page_cost
(4.0)、seq_page_cost (1.0),参数后面括号里的是默认值,这些参数值可以根据情况改变。传统上,它们以抓取顺序页的成本作为基准单位,也就是将seq_page_cost 设为
1.0 ,同时其它参数是对照它来设置的。
就到这儿吧。
------------
转载请注明出处,来自博客:
blog.csdn.net/beiigang
beigang.iteye.com
分享到:
相关推荐
三、 pg_attrdef: pg_attrdef: pg_attrdef:pg_attrdef:pg_attrdef:pg_attrdef:pg_attrdef:pg_attrdef:pg_attrdef: . 63 四、 pg_authid: pg_authid: pg_authid: pg_authid:pg_authid: 64 五、 pg_auth_members: pg_...
中文手册介绍了如何使用pgAdmin维护PostgreSQL数据库。 pgAdmin支持数据库服务器7.3及以上版本。 对于低于7.3版本的请使用pgAdmin II。
查询sql的死锁进程,查找并杀死。解决生产数据库中卡死的现象。postgresql查询死锁以及杀死死锁进程sql
PostgreSQL技术内幕:事务处理深度探索.docx
NULL 博文链接:https://haige18.iteye.com/blog/1746527
一、服务器进程的启动和关闭: 下面是pg_ctl命令的使用方法和常用选项,需要指出的是,该命令是postgres命令的封装体,因此在使用上比直接使用postgres更加方便。 代码如下: pg_ctl init[db] [-D DATADIR] [-s]...
赠送jar包:postgresql-42.3.1.jar; 赠送原API文档:postgresql-42.3.1-javadoc.jar; 赠送源代码:postgresql-42.3.1-sources.jar; 赠送Maven依赖信息文件:postgresql-42.3.1.pom; 包含翻译后的API文档:...
postgresql &pg源码安装编译教程
赠送jar包:postgresql-42.2.5.jar; 赠送原API文档:postgresql-42.2.5-javadoc.jar; 赠送源代码:postgresql-42.2.5-sources.jar; 赠送Maven依赖信息文件:postgresql-42.2.5.pom; 包含翻译后的API文档:...
嵌入式postgresql服务器为在unittests中运行postgres二进制文件提供了一种与平台无关的方法。
postgresql数据库jdbc驱动,jar包。。。。。。。。。。。。
SQL Server 2000链接服务器到PostgreSQL
1.nacos服务,适配postgresql数据库。 2.提供nacos,postgresql的创建nacos数据库脚本。 3.nacos/conf/nacos-pg.sql数据库脚本文件。 4.nacos版本1.4.2。
存储过程 postgresql postgresql存储过程
PostgreSQL中国社区资深数据库专家、沃趣科技首席数据库架构师撰写,PostgreSQL数据库领域经典著作 系统讲解PostgreSQL技术内幕,深入分析PostgreSQL特色功能,包含大量来自实际生产环境的经典案例和经验总结 ...
linux搭建postgresql、postgis、pg_pathman环境步骤以及需要的软件包
关于PostGreSQL中的存储过程 PostGreSQL是一个开源的数据库
PostgreSQL9.6.0-CN中文指南 PG DBA必备
何为 PostgreSQL? PostgreSQL 简史 格式约定 更多信息 臭虫汇报指导 I. 教程 1. 从头开始 2. SQL 语言 3. 高级特性 II. SQL 语言 4. SQL 语法 5. 数据定义 6. 数据操作 7. 查询 8. 数据类型 9. ...
PostgreSQL客户端,pgadmin3,安装后,配置连接,便可使用