PostgreSQL的prepare 和 execute 动作背后

简介:

我给PostgreSQL的源代码加入了调试信息以后,会有如下表现:

我执行Prepare:

postgres=# prepare s(int) as select * from tst01 t where id < $1;
PREPARE
postgres=# 

背后的反应:

复制代码
** In PostgresMain 
In exec_simple_query loop for parsetree_list++++++++++++++++++++++++++Before pg_plan_queries
***************In pg_plan_queries -------start
................In pg_plan_queries...query->commandType == CMD_UTILITY
***************In pg_plan_queries -------end
In exec_simple_query loop for parsetree_list++++++++++++++++++++++++++After pg_plan_queries

...In exec_simple_query....Before PortalRun
.....In PortalRun ------------start
.......In PortalRunUtility ---------------start
.........In ProcessUtility----Start
.........In ProcessUtility----End
.......In PortalRunUtility ---------------end
.....In PortalRun ------------end
...In exec_simple_query....After PortalRun
复制代码

接着执行 Execute:

复制代码
postgres=# execute s(2);
 id 
----
1
(1 row)

postgres=# 
复制代码

背后的反应:

复制代码
In exec_simple_query loop for parsetree_list++++++++++++++++++++++++++Before pg_plan_queries
***************In pg_plan_queries -------start
................In pg_plan_queries...query->commandType == CMD_UTILITY
***************In pg_plan_queries -------end
In exec_simple_query loop for parsetree_list++++++++++++++++++++++++++After pg_plan_queries


...In exec_simple_query....Before PortalRun
.....In PortalRun ------------start
xxxxxxIn FillPortalStore ...........start
.......In PortalRunUtility ---------------start
.........In ProcessUtility----Start
..........In standard_ProcessUtility ... Before ExecuteQuery 
xxxxxxxxxxxIn ExecuteQuery--------start
++++++++++++In GetCachedPlan ........start
.............In BuildCachedPlan, Before pg_plan_queries 
***************In pg_plan_queries -------start
................In pg_plan_queries...query->commandType != CMD_UTILITY
..................In pg_plan_query........start
*******************In planner ........start
___________________In standard_planner........start
********************In subquery_planner........start
++++++++++++++++++++++In grouping_planner......start
************************In query_planner......start
........................In make_one_rel......start
...........................In set_base_rel_pathlists......start
-----------------------------In set_rel_pathlist......start
******************************In set_plain_rel_pathlist......start
-------------------------------Before add_path of seqscan
-------------------------------After add_path of seqscan

-------------------------------Before create_index_paths
-------------------------------After create_index_path

-------------------------------Before create_tidscan_paths
-------------------------------After create_tidscan_paths

-------------------------------Before set_cheapest
-------------------------------After set_cheapest

******************************In set_plain_rel_pathlist......end
-----------------------------In set_rel_pathlist......end
...........................In set_base_rel_pathlists......end
........................In make_one_rel......end
************************In query_planner......end
++++++++++++++++++++++In grouping_planner......end
********************In subquery_planner........end
___________________In standard_planner........end
*******************In planner ........end
..................In pg_plan_query........end
***************In pg_plan_queries -------end
.............In BuildCachedPlan, After pg_plan_queries 
++++++++++++In GetCachedPlan ........end

.....In PortalRun ------------start
.....In PortalRun ------------end
xxxxxxxxxxxIn ExecuteQuery--------end
..........In standard_ProcessUtility ... After ExecuteQuery 
.........In ProcessUtility----End
.......In PortalRunUtility ---------------end
xxxxxxIn FillPortalStore ...........end
.....In PortalRun ------------end
...In exec_simple_query....After PortalRun
复制代码

按照对过去版本的认识,应当是PortalRun的时候单纯执行计划。

但是preapre....execute 方式,把它破坏了。

可以看到,prepare时候,不进行path的生成。

execute 的时候,在PortalRun的阶段,通过 ExecuteQuery->GetCachedPlan->BuildCachedPlan,

来生成path和确定plan。

不过要注意到一点是,我所执行的上述的例子中,并没有导致 param_info 非空。

可以说,这种针对单一表的preapre execute,是把执行计划的生成推后了,但是并不等于它就是 Parameterized Path。






本文转自健哥的数据花园博客园博客,原文链接:http://www.cnblogs.com/gaojian/p/3144475.html,如需转载请自行联系原作者


相关实践学习
使用PolarDB和ECS搭建门户网站
本场景主要介绍如何基于PolarDB和ECS实现搭建门户网站。
阿里云数据库产品家族及特性
阿里云智能数据库产品团队一直致力于不断健全产品体系,提升产品性能,打磨产品功能,从而帮助客户实现更加极致的弹性能力、具备更强的扩展能力、并利用云设施进一步降低企业成本。以云原生+分布式为核心技术抓手,打造以自研的在线事务型(OLTP)数据库Polar DB和在线分析型(OLAP)数据库Analytic DB为代表的新一代企业级云原生数据库产品体系, 结合NoSQL数据库、数据库生态工具、云原生智能化数据库管控平台,为阿里巴巴经济体以及各个行业的企业客户和开发者提供从公共云到混合云再到私有云的完整解决方案,提供基于云基础设施进行数据从处理、到存储、再到计算与分析的一体化解决方案。本节课带你了解阿里云数据库产品家族及特性。
目录
相关文章
|
关系型数据库 PostgreSQL
|
关系型数据库 PostgreSQL
|
关系型数据库 PostgreSQL SQL
|
存储 关系型数据库 测试技术
拯救海量数据:PostgreSQL分区表性能优化实战手册(附压测对比)
本文深入解析PostgreSQL分区表的核心原理与优化策略,涵盖性能痛点、实战案例及压测对比。首先阐述分区表作为继承表+路由规则的逻辑封装,分析分区裁剪失效、全局索引膨胀和VACUUM堆积三大性能杀手,并通过电商订单表崩溃事件说明旧分区维护的重要性。接着提出四维设计法优化分区策略,包括时间范围分区黄金法则与自动化维护体系。同时对比局部索引与全局索引性能,展示后者在特定场景下的优势。进一步探讨并行查询优化、冷热数据分层存储及故障复盘,解决分区锁竞争问题。
1751 2
|
关系型数据库 分布式数据库 数据库
|
关系型数据库 分布式数据库 PolarDB
《阿里云产品手册2022-2023 版》——PolarDB for PostgreSQL
《阿里云产品手册2022-2023 版》——PolarDB for PostgreSQL
681 0
|
存储 缓存 关系型数据库
|
存储 SQL 并行计算
PolarDB for PostgreSQL 开源必读手册-开源PolarDB for PostgreSQL架构介绍(中)
PolarDB for PostgreSQL 开源必读手册-开源PolarDB for PostgreSQL架构介绍
878 0
|
存储 算法 安全
PolarDB for PostgreSQL 开源必读手册-开源PolarDB for PostgreSQL架构介绍(下)
PolarDB for PostgreSQL 开源必读手册-开源PolarDB for PostgreSQL架构介绍
743 0

推荐镜像

更多