PgSQL · 新特征 · PG11并行Hash Join介绍

本文涉及的产品
云数据库 RDS SQL Server,独享型 2核4GB
云原生数据库 PolarDB 分布式版,标准版 2核8GB
RDS MySQL Serverless 基础系列,0.5-2RCU 50GB
简介: 关键字Parallelized, Parallel-aware hash joins摘要本文将介绍一下PostgreSQL 11 beta 1 新增的全并行Hash join特征。 将给读者介绍一下postgreSQL并行的设计与实现,并分析一下PostgreSQL的全并行hash join的设计与实现细节。

关键字

Parallelized, Parallel-aware hash joins

摘要

本文将介绍一下PostgreSQL 11 beta 1 新增的全并行Hash join特征。 将给读者介绍一下postgreSQL并行的设计与实现,并分析一下PostgreSQL的全并行hash join的设计与实现细节。

1.0 并行背景简介

PostgreSQL 从9.6版本开始提供并行特征,并在后续的版本中不断的迭代晚上对各种功能的并行支持。 20180627161744.png

20180627161708.png

上图:描述并行各个版本中的支持 本文将给主要给大家介绍一下hash join和并行创建索引的实现。

2.0 PostgreSQL并行设计与实现

简单讲PostgreSQL通过在查询计划当中引入gather和gatherMerge算子来决定是否在查询树中开始并行执行的部分。在执行gather或ganterMerge节点的时候,这两个节点就成为起停并行执行的出入口节点。 ppic.jpg

上图显示了查询怎样从原来的执行计划,通过gather节点实现并行执行的演变过程。其中gather是并行分发/汇总节点。gatherMerge是用来实现分发/按顺序汇总执行的节点。在执行的gather节点的时候,它会初始化并行执行所需要的资源,以及并行控制结构。并启动并行worker开始工作,通过共享内存来接受worker返回的数据。

3.0并行Hash Join

关于并行hash join的支持,在之前的版本已经有对hash join的并行支持,但是对于hash join并行并没有做的很彻底。之前只是在外表部分实现了并行。 内表处理是在每一个并行分支上面都做一份完整的hash表。在11版本中实现了内表部分的并行处理。

3.1并行Hash Join实现步骤

3.1.1 Hash Join状态机

并行hash join的实现与非并行的hash join大致上是一致的。可以共用一套状态机如下: hj状态机2.png

3.1.2 Hash Table状态机

在PostgreSQL 11版本中,主要增加了并行构建hash table的实现。其中关于hash table构建的状态机如下: ht状态机.png

每个参与并行hash join的并行任务,它必须能够知道当前自己已经完成了多少工作,因为并行任务并不需要等待其他任务一同开始。因此在任务的一些关键节点上我们需要同步所有任务的状态,确定所有任务都到这这个点之后,然后启动下一个状态的任务。这里并行用一系列屏障机制来协调并行任务的同步进入下一状态并开始执行。

其中并行Hash INNER步骤根据需要实际数据的大小可能会调整batch和bucket中tuple的数据。状态机如下:

3.1.2.1 Batch扩展:

batch.png

3.1.2.2 Bucket扩展:

bucket.png 分别使用两组屏障独立处理batch和bucket的扩展;

3.1.2.3PHJ_BUILD_HASHING_OUTER阶段

关于PHJ_BUILD_HASHING_OUTER阶段,仅仅当多个batch joins的时候会用到,因为这里我们需要讲outer表也按照同样的方式hash到相对应得batch,这样就可以独立的处理每一个batch。

4.0 总结

这篇文章主要是high level的给大家介绍了一下并行全hash join如何实现,后续如果有时间会继续分析更加详细的实现细节。

相关实践学习
使用PolarDB和ECS搭建门户网站
本场景主要介绍基于PolarDB和ECS实现搭建门户网站。
阿里云数据库产品家族及特性
阿里云智能数据库产品团队一直致力于不断健全产品体系,提升产品性能,打磨产品功能,从而帮助客户实现更加极致的弹性能力、具备更强的扩展能力、并利用云设施进一步降低企业成本。以云原生+分布式为核心技术抓手,打造以自研的在线事务型(OLTP)数据库Polar DB和在线分析型(OLAP)数据库Analytic DB为代表的新一代企业级云原生数据库产品体系, 结合NoSQL数据库、数据库生态工具、云原生智能化数据库管控平台,为阿里巴巴经济体以及各个行业的企业客户和开发者提供从公共云到混合云再到私有云的完整解决方案,提供基于云基础设施进行数据从处理、到存储、再到计算与分析的一体化解决方案。本节课带你了解阿里云数据库产品家族及特性。
目录
相关文章
|
JSON 固态存储 关系型数据库
【DB吐槽大会】第43期 - PG 倒排索引启动和recheck代价高
大家好,这里是DB吐槽大会,第43期 - PG 倒排索引启动和recheck代价高
|
机器学习/深度学习 SQL 算法
【DB吐槽大会】第58期 - PG 复杂JOIN优化器有巨大提升空间
大家好,这里是DB吐槽大会,第58期 - PG 复杂JOIN优化器有巨大提升空间
|
SQL 分布式计算 并行计算
PostgreSQL 并行计算解说 之19 - parallel hash join
标签 PostgreSQL , cpu 并行 , smp 并行 , 并行计算 , gpu 并行 , 并行过程支持 背景 PostgreSQL 11 优化器已经支持了非常多场合的并行。简单估计,已支持27余种场景的并行计算。 parallel seq scan
993 0
|
存储 运维 关系型数据库
|
关系型数据库
MySQL8.0 · 引擎分析 · InnoDB history list 无法降到0的原因
熟悉InnoDB的朋友都知道,innodb的history list长度代表了有多少undo日志还没有被清理掉,可以通过show engine innodb status 命令来获得。如果发现history list的长度越大,要么就是实例的复杂非常高,要么就是可能有大查询,或者事务没提交,导致Undo log无法分析。
3590 0
|
关系型数据库 MySQL 索引
MySQL · 捉虫动态 · order by limit 造成优化器选择索引错误
问题描述 bug 触发条件如下: 优化器先选择了 where 条件中字段的索引,该索引过滤性较好; SQL 中必须有 order by limit 从而引导优化器尝试使用 order by 字段上的索引进行优化,最终因代价问题没有成功。 复现case 表结构 create table t
7745 0
|
关系型数据库 索引
MySQL · 源码分析 · 聚合函数(Aggregate Function)的实现过程
--- title: MySQL · 源码分析 · 聚合函数(Aggregate Function)的实现过程 author: 道客 --- ## 总览 聚合函数(Aggregate Function)顾名思义,就是将一组数据进行统一计算,常常用于分析型数据库中,当然在应用中是非常重要不可或缺的函数计算方式。比如我们常见的COUNT/AVG/SUM/MIN/MAX等等。本文主要分析下
1865 0
|
存储 SQL 关系型数据库
MySQL · 引擎特性 · Cost Model,直方图及优化器开销优化
MySQL当前已经发布到MySQL8.0版本,在新的版本中,可以看到MySQL之前被人诟病的优化器部分做了很多的改动,由于笔者之前的工作环境是5.6,最近切换到最新的8.0版本,本文涵盖了一些本人感兴趣的和优化器相关的部分,主要包括MySQL5.7的cost model以及MySQL8.0的直方图功能。
1455 0
|
关系型数据库 测试技术 数据库
PgSQL · 内核优化 · Hybrid DB for PG 赋能向量化执行和查询子树封装
背景 Hybrid DB for postgresql简介: 随着大数据时代的不断演进, 用户对于数据的分析能力的需要提出了越来越高的要求。 Hybrid DB for postgres(本文后续将会使用HDBP来代表)是一款基于Greenplum开源项目的分析型数据库。
2066 0