PostgreSQL 10.0 preview 多核并行增强 - 索引扫描、子查询、VACUUM、fdw/csp钩子

本文涉及的产品
云原生数据库 PolarDB MySQL 版,Serverless 5000PCU 100GB
云原生数据库 PolarDB 分布式版,标准版 2核8GB
云数据库 RDS MySQL Serverless,0.5-2RCU 50GB
简介:

标签

PostgreSQL , 10.0 , 并行计算 , 索引扫描 , 子查询 , VACUUM , 外部表并行


背景

PostgreSQL 9.6推出的多核并行计算特性,支持全表扫描,hash join,聚合操作。

10.0 在此基础上,增加了更多的支持。

1. Parallel bitmap heap scan

2. Parallel Index Scans

3. Parallel Merge Join

4. parallelize queries containing subplans

5. Block level parallel vacuum

6. Extending the parallelism for index-only scans

7. ParallelFinish Hook of FDW/CSP

这是一个fdw钩子,用于在访问FDW/CSP的node(backend process)的内存上下文释放前,让上面的gather node获得上下文的控制权。

从而,从DSM中获得每个fdw node通道的统计信息,比如pg_strom项目,custom scan阶段的dma数据传输的速度,GPU的运算时间等。

使用这个钩子,就可以达到以上目的。

Hello,  
  
The attached patch implements the suggestion by Amit before.  
  
What I'm motivated is to collect extra run-time statistics specific  
to a particular ForeignScan/CustomScan, not only the standard  
Instrumentation; like DMA transfer rate or execution time of GPU  
kernels in my case.  
  
Per-node DSM toc is one of the best way to return run-time statistics  
to the master backend, because FDW/CSP can assign arbitrary length of  
the region according to its needs. It is quite easy to require.  
However, one problem is, the per-node DSM toc is already released when  
ExecEndNode() is called on the child node of Gather.  
  
This patch allows extensions to get control on the master backend's  
context when all the worker node gets finished but prior to release  
of the DSM segment. If FDW/CSP has its special statistics on the  
segment, it can move to the private memory area for EXPLAIN output  
or something other purpose.  
  
One design consideration is whether the hook shall be called from  
ExecParallelRetrieveInstrumentation() or ExecParallelFinish().  
The former is a function to retrieve the standard Instrumentation  
information, thus, it is valid only if EXPLAIN ANALYZE.  
On the other hands, if we put entrypoint at ExecParallelFinish(),  
extension can get control regardless of EXPLAIN ANALYZE, however,  
it also needs an extra planstate_tree_walker().  
  
Right now, we don't assume anything onto the requirement by FDW/CSP.  
It may want run-time statistics regardless of EXPLAIN ANALYZE, thus,  
hook shall be invoked always when Gather node confirmed termination  
of the worker processes.  
  
Thanks,  
--  
NEC OSS Promotion Center / PG-Strom Project  
KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com>  

这个patch的讨论,详见邮件组,本文末尾URL。

PostgreSQL社区的作风非常严谨,一个patch可能在邮件组中讨论几个月甚至几年,根据大家的意见反复的修正,patch合并到master已经非常成熟,所以PostgreSQL的稳定性也是远近闻名的。

参考

https://commitfest.postgresql.org/13/812/

https://commitfest.postgresql.org/13/849/

https://commitfest.postgresql.org/13/918/

https://commitfest.postgresql.org/13/941/

https://commitfest.postgresql.org/13/954/

https://commitfest.postgresql.org/13/867/

https://commitfest.postgresql.org/13/917/

相关实践学习
使用PolarDB和ECS搭建门户网站
本场景主要介绍基于PolarDB和ECS实现搭建门户网站。
阿里云数据库产品家族及特性
阿里云智能数据库产品团队一直致力于不断健全产品体系,提升产品性能,打磨产品功能,从而帮助客户实现更加极致的弹性能力、具备更强的扩展能力、并利用云设施进一步降低企业成本。以云原生+分布式为核心技术抓手,打造以自研的在线事务型(OLTP)数据库Polar DB和在线分析型(OLAP)数据库Analytic DB为代表的新一代企业级云原生数据库产品体系, 结合NoSQL数据库、数据库生态工具、云原生智能化数据库管控平台,为阿里巴巴经济体以及各个行业的企业客户和开发者提供从公共云到混合云再到私有云的完整解决方案,提供基于云基础设施进行数据从处理、到存储、再到计算与分析的一体化解决方案。本节课带你了解阿里云数据库产品家族及特性。
相关文章
|
1月前
|
关系型数据库 分布式数据库 数据库
PolarDB常见问题之加了索引但是查询没有使用如何解决
PolarDB是阿里云推出的下一代关系型数据库,具有高性能、高可用性和弹性伸缩能力,适用于大规模数据处理场景。本汇总囊括了PolarDB使用中用户可能遭遇的一系列常见问题及解答,旨在为数据库管理员和开发者提供全面的问题指导,确保数据库平稳运行和优化使用体验。
|
5月前
|
消息中间件 存储 关系型数据库
PostgreSQL技术大讲堂 - 第33讲:并行查询管理
PostgreSQL从小白到专家,技术大讲堂 - 第33讲:并行查询管理
289 1
|
4月前
|
关系型数据库 MySQL 分布式数据库
PolarDB MySQL版并行查询技术探索与实践
PolarDB MySQL版并行查询技术探索与实践 PolarDB MySQL版在企业级查询加速特性上进行了深度技术探索,其中并行查询作为其重要组成部分,已经在线稳定运行多年,持续演进。本文将详细介绍并行查询的背景、挑战、方案、特性以及实践。
108 2
|
2月前
|
SQL 算法 关系型数据库
PolarDB-X的XPlan索引选择
对于数据库来说,正确的选择索引是基本的要求,选错索引轻则导致查询缓慢,重则导致数据库整体不可用。PolarDB-X存在多种不同的索引,局部索引、全局索引、列存索引、归档表索引。本文主要介绍一种CN上的局部索引算法:XPlan索引选择。
125756 13
PolarDB-X的XPlan索引选择
|
3月前
|
关系型数据库 定位技术 索引
在关系型数据库中,常见的索引种类包括哪些
在关系型数据库中,常见的索引种类包括哪些
486 0
|
4月前
|
SQL 关系型数据库 分布式数据库
深度解析PolarDB数据库并行查询技术
深度解析PolarDB数据库并行查询技术:加速SQL执行的关键问题和核心技术 随着数据规模的不断扩大,用户SQL的执行时间越来越长,这不仅对数据库的优化能力提出更高的要求,并且对数据库的执行模式也提出了新的挑战。为了解决这个问题,许多数据库系统,包括Oracle、SQL Server等,都开始提供并行查询引擎的支持,以充分利用系统资源,达到加速SQL执行的效果。本文将深入探讨基于代价进行并行优化、并行执行的云数据库的并行查询引擎的关键问题和核心技术。
123 2
|
6月前
|
关系型数据库 MySQL 分布式数据库
PolarDB MySQL版重磅推出的列存索引(
PolarDB MySQL版重磅推出的列存索引(
340 1
|
6月前
|
关系型数据库 Go 数据库
《提高查询速度:PostgreSQL索引实用指南》
《提高查询速度:PostgreSQL索引实用指南》
362 0
|
6月前
|
SQL 缓存 关系型数据库
PolarDB-X 混沌测试实践:如何衡量数据库索引选择能力
随着PolarDB分布式版的不断演进,功能不断完善,新的特性不断增多,整体架构扩大的同时带来了测试链路长,出现问题前难发现,出现问题后难排查等等问题。原有的测试框架已经难以支撑实际场景的复杂模拟测试。因此,我们实现了一个基于业务场景面向优化器索引选择的混沌查询实验室,本文之后简称为CEST(complex environment simulation test)。
|
7月前
|
关系型数据库 分布式数据库 数据库
PolarDB for PostgreSQL 14:全局索引
PolarDB for PostgreSQL 14 相较于 PostgreSQL 14,提供了更多企业级数据库的特性。本实验将体验其中的全局索引功能。
754 0

相关产品

  • 云原生数据库 PolarDB