PostgreSQL 10.1 手册_部分 II. SQL 语言_第 15章 并行查询_15.3. 并行计划

本文涉及的产品
云原生数据库 PolarDB PostgreSQL 版,标准版 2核4GB 50GB
云原生数据库 PolarDB MySQL 版,通用型 2核8GB 50GB
简介: 15.3. 并行计划 15.3.1. 并行扫描 15.3.2. 并行连接 15.3.3. 并行聚合 15.3.4. 并行计划小贴士 因为每个工作者只执行完成计划的并行部分,所以不可能简单地产生一个普通查询计划并使用多个工作者运行它。

15.3. 并行计划

因为每个工作者只执行完成计划的并行部分,所以不可能简单地产生一个普通查询计划并使用多个工作者运行它。每个工作者都会产生输出结果集的一个完全拷贝,因而查询并不会比普通查询运行得更快甚至还会产生不正确的结果。相反,计划的并行部分一定被查询优化器在内部当作一个部分计划。也就是说,一定要这样来创建计划,使得每个将执行该计划的进程只产生输出行的一个子集,这样可以保证每个需要被输出的行刚好会被合作进程产生一次。 通常,这意味着查询驱动表上的扫描必须是并行感知扫描。

15.3.1. 并行扫描

目前支持以下类型的并行感知表扫描。

  • 并行顺序扫描中,表格的块将在协作过程中分配。 块一次发放一个,所以访问表仍然是连续的。

  • 在一个并行位图堆扫描中,选择一个进程作为领导者。 该进程执行一个或多个索引的扫描并构建指示需要访问哪些表块的位图。 然后这些块在并行顺序扫描中在协作进程中分配。换句话说, 堆扫描是并行执行的,但底层索引扫描不是。

  • 并行索引扫描并行仅索引的扫描中, 协作进程轮流从索引读取数据。目前, 并行索引扫描仅支持btree索引。每个进程将声明一个索引块, 并将扫描并返回该块引用的所有元组;其他进程可以同时从不同的索引块返回元组。 并行btree扫描的结果以每个工作进程内的排序顺序返回。

其他扫描类型(如非Btree索引的扫描)可能会在将来支持并行扫描。

15.3.2. 并行连接

就像在非平行计划中一样,可以使用嵌套循环、 散列连接或合并连接将驱动表连接到一个或多个其他表。 连接的内侧可以是规划器支持的任何类型的非平行计划, 只要在并行工作者内运行是安全的。例如,如果选择了嵌套循环连接, 则内部计划可能是索引扫描,它会查找从连接外侧获取的值。

每个工作者将全部执行连接的内侧。这对于嵌套循环通常不是问题, 但对于涉及散列或合并连接的情况可能效率低下。例如,对于散列连接, 此限制意味着在每个工作进程中构建了一个相同的散列表, 这对于小型表中的连接工作良好,但在内部表很大时可能效率不高。 对于合并连接,这可能意味着每个工作者执行内部关系的一个单独排序, 这可能会很慢。当然,在这种并行计划效率低下的情况下, 查询规划器通常会选择其他计划(可能不使用并行性)。

15.3.3. 并行聚合

PostgreSQL通过两个阶段的聚合来支持并行聚合。第一次, 每个参与查询计划并行部分执行的进程执行一个聚合步骤, 为进程发现的每个分组产生一个部分结果。这在计划中反映为一个 PartialAggregate节点。第二次,部分结果被通过Gather 或Gather Merge节点传输给领导者。最后, 领导者对所有工作者的部分结果进行重聚合以得到最终的结果。 这在计划中反映为一个FinalizeAggregate节点。

因为Finalize Aggregate节点运行在领导者进程上, 所以与输入行的数量相比产生相对大量组的查询对于查询计划者来说显得较不利。 例如,在最坏的情况下,Finalize Aggregate节点看到的组的数量可能与Partial Aggregate 阶段中所有工作进程看到的输入行的数量一样多。对于这种情况, 使用并行聚合显然没有性能优势。查询规划器在规划过程中考虑到了这一点, 并且在这种情况下不太可能选择并行聚合。

并行聚合并不能支持所有的情况。每个聚合对于并行机制一定要是安全的,并且必须有一个结合函数。如果聚合有一个internal类型的转移状态,它必须有序列化和反序列化函数。详见CREATE AGGREGATE。 如果任何聚合函数调用包含DISTINCTORDER BY子句, 则不支持并行聚合,并且对于有序集聚合或者查询涉及GROUPING SETS时也不支持并行聚合。只有当查询中涉及的所有连接也是计划中并行不分的一部分时,才能使用并行聚合。

15.3.4. 并行计划小贴士

如果我们想要一个查询能产生并行计划但事实上又没有产生,可以尝试减小parallel_setup_cost或者parallel_tuple_cost。当然,这个计划可能比规划器优先产生的顺序计划还要慢,但也不总是如此。如果将这些设置为很小的值(例如把它们设置为零)也不能得到并行计划,那就可能是有某种原因导致查询规划器无法为你的查询产生并行计划。可能的原因可见第 15.2 节第 15.4 节

在执行一个并行计划时,可以用EXPLAIN (ANALYZE,VERBOSE)来显示每个计划节点在每个工作者上的统计信息。这些信息有助于确定是否所有的工作被均匀地分发到所有计划节点以及从总体上理解计划的性能特点。

本文转自PostgreSQL中文社区,原文链接:15.3. 并行计划

相关实践学习
使用PolarDB和ECS搭建门户网站
本场景主要介绍基于PolarDB和ECS实现搭建门户网站。
阿里云数据库产品家族及特性
阿里云智能数据库产品团队一直致力于不断健全产品体系,提升产品性能,打磨产品功能,从而帮助客户实现更加极致的弹性能力、具备更强的扩展能力、并利用云设施进一步降低企业成本。以云原生+分布式为核心技术抓手,打造以自研的在线事务型(OLTP)数据库Polar DB和在线分析型(OLAP)数据库Analytic DB为代表的新一代企业级云原生数据库产品体系, 结合NoSQL数据库、数据库生态工具、云原生智能化数据库管控平台,为阿里巴巴经济体以及各个行业的企业客户和开发者提供从公共云到混合云再到私有云的完整解决方案,提供基于云基础设施进行数据从处理、到存储、再到计算与分析的一体化解决方案。本节课带你了解阿里云数据库产品家族及特性。
相关文章
|
4月前
|
关系型数据库 Go 网络安全
go语言中PostgreSQL驱动安装
【11月更文挑战第2天】
190 5
|
15天前
|
SQL 关系型数据库 OLAP
云原生数据仓库AnalyticDB PostgreSQL同一个SQL可以实现向量索引、全文索引GIN、普通索引BTREE混合查询,简化业务实现逻辑、提升查询性能
本文档介绍了如何在AnalyticDB for PostgreSQL中创建表、向量索引及混合检索的实现步骤。主要内容包括:创建`articles`表并设置向量存储格式,创建ANN向量索引,为表增加`username`和`time`列,建立BTREE索引和GIN全文检索索引,并展示了查询结果。参考文档提供了详细的SQL语句和配置说明。
30 1
|
22天前
|
SQL 数据可视化 IDE
SQL做数据分析的困境,查询语言无法回答的真相
SQL 在简单数据分析任务中表现良好,但面对复杂需求时显得力不从心。例如,统计新用户第二天的留存率或连续活跃用户的计算,SQL 需要嵌套子查询和复杂关联,代码冗长难懂。Python 虽更灵活,但仍需变通思路,复杂度较高。相比之下,SPL(Structured Process Language)语法简洁、支持有序计算和分组子集保留,具备强大的交互性和调试功能,适合处理复杂的深度数据分析任务。SPL 已开源免费,是数据分析师的更好选择。
|
5月前
|
SQL Oracle 关系型数据库
SQL语言的主要标准及其应用技巧
SQL(Structured Query Language)是数据库领域的标准语言,广泛应用于各种数据库管理系统(DBMS)中,如MySQL、Oracle、SQL Server等
190 9
|
5月前
|
SQL 关系型数据库 MySQL
Go语言项目高效对接SQL数据库:实践技巧与方法
在Go语言项目中,与SQL数据库进行对接是一项基础且重要的任务
144 11
|
6月前
|
SQL 关系型数据库 C语言
PostgreSQL SQL扩展 ---- C语言函数(三)
可以用C(或者与C兼容,比如C++)语言编写用户自定义函数(User-defined functions)。这些函数被编译到动态可加载目标文件(也称为共享库)中并被守护进程加载到服务中。“C语言函数”与“内部函数”的区别就在于动态加载这个特性,二者的实际编码约定本质上是相同的(因此,标准的内部函数库为用户自定义C语言函数提供了丰富的示例代码)
|
7月前
|
运维 监控 关系型数据库
PostgreSQL运维核心技能之掌握并行查询
PostgreSQL运维核心技能之掌握并行查询
157 9
|
7月前
|
SQL 存储 关系型数据库
PostgreSQL核心之SQL基础学习
PostgreSQL核心之SQL基础学习
99 3
|
7月前
|
SQL 关系型数据库 MySQL
|
7月前
|
SQL 存储 大数据
SQL 语言发展史简直太震撼啦!从诞生到现代数据处理,见证一场奇妙的演变之旅,快来感受!
【8月更文挑战第31天】SQL(结构化查询语言)自20世纪70年代由IBM研究员E.F. Codd提出以来,已成为现代数据处理不可或缺的一部分。它最初简化了层次和网状模型中复杂的存储与检索问题,通过基本的SELECT、FROM和WHERE关键字实现了数据查询。80年代,SQL在商业数据库中广泛应用,引入了GROUP BY、HAVING和ORDER BY等功能,增强了数据分析能力。90年代,互联网和企业信息化推动了SQL的进一步优化与扩展,支持分布式数据库和数据仓库等技术。
155 0