PostgreSQL在何处处理 sql查询之二十七

本文涉及的产品
云原生数据库 PolarDB MySQL 版,通用型 2核8GB 50GB
云原生数据库 PolarDB PostgreSQL 版,标准版 2核4GB 50GB
简介:

接前面,仔细看这个 :这 add_base_rels_to_query 是个递归调用嘛。

想像一下: select  * from tst01  where id in (select sid from tst02)  or id in (select sid from tst03) 之类的,此函数将层层深入,构造一个二叉树式样的语法树。

复制代码
void
add_base_rels_to_query(PlannerInfo *root, Node *jtnode)
{
    if (jtnode == NULL)
        return;
    if (IsA(jtnode, RangeTblRef))
    {
        int    varno = ((RangeTblRef *) jtnode)->rtindex;
        (void) build_simple_rel(root, varno, RELOPT_BASEREL);
    }
    else if (IsA(jtnode, FromExpr))
    {
        FromExpr   *f = (FromExpr *) jtnode;
        ListCell   *l;

        foreach(l, f->fromlist)
            add_base_rels_to_query(root, lfirst(l));
    }
    else if (IsA(jtnode, JoinExpr))
    {
        JoinExpr   *j = (JoinExpr *) jtnode;

        add_base_rels_to_query(root, j->larg);
        add_base_rels_to_query(root, j->rarg);
    }
    else
        elog(ERROR, "unrecognized node type: %d",
             (int) nodeTag(jtnode));
}
复制代码

 这个时候,我想到一个问题,在PostgreSQL中,有没有并行查询的可能呢?

那么,再上溯到更高的层面,再次梳理一下:

exec_simple_query中调用 了 plan_tree_list,从语法分析树得到了计划树...执行 PortalRun。

而上面的 add_base_rels_to_query 是plan_tree_list 里的一部分。

调用关系如下:

plan_tree_list -->pg_plan_queries-->pg_plan_query-->planner

planner-->subquery_planner-->groupingplanner

groupingplanner-->query_planner-->add_base_rels_to_query

复制代码
/*
  * exec_simple_query
  *
  * Execute a "simple Query" protocol message.
  */
 static void
 exec_simple_query(const char *query_string)
 {
     ...
     isTopLevel = (list_length(parsetree_list) == 1);
     ...
     foreach(parsetree_item, parsetree_list)
     {
         ...
         querytree_list = pg_analyze_and_rewrite(parsetree, query_string,
                                                 NULL, 0);
 
         plantree_list = pg_plan_queries(querytree_list, 0, NULL);
         ...
 
         /*
          * Create unnamed portal to run the query or queries in. If there
          * already is one, silently drop it.
          */
         portal = CreatePortal("", true, true);
         /* Don't display the portal in pg_cursors */
         portal->visible = false;
 
         /*
          * We don't have to copy anything into the portal, because everything
          * we are passing here is in MessageContext, which will outlive the
          * portal anyway.
          */
         PortalDefineQuery(portal,
                           NULL,
                           query_string,
                           commandTag,
                           plantree_list,
                           NULL);
 
         /*
          * Start the portal.
          *
          * If we took a snapshot for parsing/planning, the portal may be able
          * to reuse it for the execution phase.  Currently, this will only
          * happen in PORTAL_ONE_SELECT mode.  But even if PortalStart doesn't
          * end up being able to do this, keeping the parse/plan snapshot
          * around until after we start the portal doesn't cost much.
          */
         PortalStart(portal, NULL, 0, snapshot_set);
         ...
 
         /*
          * Run the portal to completion, and then drop it (and the receiver).
          */
         (void) PortalRun(portal,
                          FETCH_ALL,
                          isTopLevel,
                          receiver,
                          receiver,
                          completionTag);
 
         (*receiver->rDestroy) (receiver);
 
         PortalDrop(portal, false);
 
         ...
     }                            /* end loop over parsetrees */
 
     /*
      * Close down transaction statement, if one is open.
      */
     finish_xact_command();
     ...
 }
复制代码

 加入调试信息,看看一个带子查询的SQL,能否有并行查询的可能。

复制代码
[postgres@lex pgsql]$ ./bin/psql
psql (9.2.1)
Type "help" for help.

postgres=# select * from tst01 where id IN (select sid from tst02) or id IN (select sid from tst03);
 id  
-----
 100
 200
(2 rows)

postgres=# 
复制代码

看后台的信息,知道planner调用了三次,PortalRun只调用了一次。

复制代码
[postgres@lex pgsql]$ ./bin/pg_ctl -D ./data start
server starting
[postgres@lex pgsql]$ LOG:  database system was shut down at 2013-05-29 10:12:02 CST
LOG:  autovacuum launcher started
LOG:  database system is ready to accept connections
In query_planner.... by process 11796
In get_relation_info ...oid of table is: 16387 ...by process 11796
In query_planner.... by process 11796
In query_planner.... by process 11796
In get_relation_info ...oid of table is: 16390 ...by process 11796
In query_planner.... by process 11796
In query_planner.... by process 11796
In get_relation_info ...oid of table is: 16384 ...by process 11796
In query_planner.... by process 11796
In PortalRun ... by 11796 
复制代码

也就是说,PostgreSQL 没有子查询的并行查询能力了?!

至少目前,它还非常地不完整:

http://postgresql.1045698.n5.nabble.com/Parallel-query-execution-td5740431.html

http://wiki.postgresql.org/wiki/Parallel_Query_Execution

各种集群方案也作不到这点:

http://www.postgresql.org/docs/current/static/different-replication-solutions.html

Many of the above solutions allow multiple servers to handle multiple queries, but none allow a single query to use multiple servers to complete faster.

对比下Oracle的:

http://miracle.blog.51cto.com/255044/147058/





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

相关实践学习
使用PolarDB和ECS搭建门户网站
本场景主要介绍基于PolarDB和ECS实现搭建门户网站。
阿里云数据库产品家族及特性
阿里云智能数据库产品团队一直致力于不断健全产品体系,提升产品性能,打磨产品功能,从而帮助客户实现更加极致的弹性能力、具备更强的扩展能力、并利用云设施进一步降低企业成本。以云原生+分布式为核心技术抓手,打造以自研的在线事务型(OLTP)数据库Polar DB和在线分析型(OLAP)数据库Analytic DB为代表的新一代企业级云原生数据库产品体系, 结合NoSQL数据库、数据库生态工具、云原生智能化数据库管控平台,为阿里巴巴经济体以及各个行业的企业客户和开发者提供从公共云到混合云再到私有云的完整解决方案,提供基于云基础设施进行数据从处理、到存储、再到计算与分析的一体化解决方案。本节课带你了解阿里云数据库产品家族及特性。
目录
相关文章
|
6天前
|
SQL 运维 监控
SQL查询太慢?实战讲解YashanDB SQL调优思路
本文是Meetup第十期“调优实战专场”的第二篇技术文章,上一篇《高效查询秘诀,解码YashanDB优化器分组查询优化手段》中,我们揭秘了YashanDB分组查询优化秘诀,本文将通过一个案例,助你快速上手YashanDB慢日志功能,精准定位“慢SQL”后进行优化。
|
3天前
|
SQL 索引
【YashanDB知识库】字段加上索引后,SQL查询不到结果
【YashanDB知识库】字段加上索引后,SQL查询不到结果
|
4天前
|
SQL 大数据 数据挖掘
玩转大数据:从零开始掌握SQL查询基础
玩转大数据:从零开始掌握SQL查询基础
72 35
|
23天前
|
SQL 关系型数据库 分布式数据库
利用 PolarDB PG 版向量化引擎,加速复杂 SQL 查询!完成任务领发财新年抱枕!
利用 PolarDB PG 版向量化引擎,加速复杂 SQL 查询!完成任务领发财新年抱枕!
|
14天前
|
SQL 关系型数据库 OLAP
云原生数据仓库AnalyticDB PostgreSQL同一个SQL可以实现向量索引、全文索引GIN、普通索引BTREE混合查询,简化业务实现逻辑、提升查询性能
本文档介绍了如何在AnalyticDB for PostgreSQL中创建表、向量索引及混合检索的实现步骤。主要内容包括:创建`articles`表并设置向量存储格式,创建ANN向量索引,为表增加`username`和`time`列,建立BTREE索引和GIN全文检索索引,并展示了查询结果。参考文档提供了详细的SQL语句和配置说明。
30 1
|
2月前
|
SQL NoSQL Java
Java使用sql查询mongodb
通过MongoDB Atlas Data Lake或Apache Drill,可以在Java中使用SQL语法查询MongoDB数据。这两种方法都需要适当的配置和依赖库的支持。希望本文提供的示例和说明能够帮助开发者实现这一目标。
63 17
|
2月前
|
SQL Oracle 关系型数据库
如何在 Oracle 中配置和使用 SQL Profiles 来优化查询性能?
在 Oracle 数据库中,SQL Profiles 是优化查询性能的工具,通过提供额外统计信息帮助生成更有效的执行计划。配置和使用步骤包括:1. 启用自动 SQL 调优;2. 手动创建 SQL Profile,涉及收集、执行调优任务、查看报告及应用建议;3. 验证效果;4. 使用 `DBA_SQL_PROFILES` 视图管理 Profile。
|
22天前
|
SQL 数据可视化 IDE
SQL做数据分析的困境,查询语言无法回答的真相
SQL 在简单数据分析任务中表现良好,但面对复杂需求时显得力不从心。例如,统计新用户第二天的留存率或连续活跃用户的计算,SQL 需要嵌套子查询和复杂关联,代码冗长难懂。Python 虽更灵活,但仍需变通思路,复杂度较高。相比之下,SPL(Structured Process Language)语法简洁、支持有序计算和分组子集保留,具备强大的交互性和调试功能,适合处理复杂的深度数据分析任务。SPL 已开源免费,是数据分析师的更好选择。
|
2月前
|
SQL Java 数据库连接
【潜意识Java】MyBatis中的动态SQL灵活、高效的数据库查询以及深度总结
本文详细介绍了MyBatis中的动态SQL功能,涵盖其背景、应用场景及实现方式。
160 6
|
关系型数据库 分布式数据库 PolarDB
《阿里云产品手册2022-2023 版》——PolarDB for PostgreSQL
《阿里云产品手册2022-2023 版》——PolarDB for PostgreSQL
402 0