PostgreSQL 商用版本EPAS(阿里云ppas) - 分区表性能优化 (堪比pg_pathman)

本文涉及的产品
云数据库 RDS MySQL,集群系列 2核4GB
推荐场景:
搭建个人博客
RDS PostgreSQL Serverless,0.5-4RCU 50GB 3个月
推荐场景:
对影评进行热评分析
云数据库 RDS SQL Server,基础系列 2核4GB
简介:

标签

PostgreSQL , EDB , ppas , epas , 分区表优化 , PG_PATHMAN


背景

PostgreSQL 在 10的版本,内置了分区表的语法,简化了以前需要写 RULE或TG+继承表功能 来实现分区表的模式。

《PostgreSQL 10.0 preview 功能增强 - 内置分区表》

《PostgreSQL 传统 hash 分区方法和性能》

但是内置分区表的性能还有改进的空间,对比了pg_pathman,性能差异是较大的,主要在plan代码这块。所以对于社区版本的用户,建议使用pg_pathman这个插件来使用分区表的功能。

《PostgreSQL 10 内置分区 vs pg_pathman perf profiling》

作为PostgreSQL的商用发行版本的PPAS,这块有非常大的性能改进。

PPAS分区表性能优化参数

edb_enable_pruning

Parameter Type: Boolean  
  
Default Value: true  
  
Range: {true | false}  
  
Minimum Scope of Effect: Per session  
  
When Value Changes Take Effect: Immediate  
  
Required Authorization to Activate: Session user  
  
When set to TRUE, edb_enable_pruning allows the query planner to early-prune partitioned tables.   
Early-pruning means that the query planner can “prune” (i.e., ignore) partitions that would   
not be searched in a query before generating query plans.   
This helps improve performance time as it eliminates the generation of query plans of   
partitions that would not be searched.  
  
Conversely, late-pruning means that the query planner prunes partitions after   
generating query plans for each partition.   
(The constraint_exclusion configuration parameter controls late-pruning.)  
  
The ability to early-prune depends upon the nature of the query in the WHERE clause.   
Early-pruning can be utilized in only simple queries with constraints of the type    
WHERE column = literal (e.g., WHERE deptno = 10).  
  
Early-pruning is not used for more complex queries such as   
WHERE column = expression (e.g., WHERE deptno = 10 + 5).  
AI 代码解读

edb_enable_pruning这个参数的功能是在生成执行计划之前,过滤掉不需要访问的对象,从而减少执行计划的开销。

注意,目前只适用于 "常量值" 的过滤。即使是immutable函数也不支持。

支持优化  
WHERE deptno = 10  
  
不支持优化  
WHERE deptno = 10 + 5  
AI 代码解读

对于不能过滤的分区,最后会在生成执行计划后,使用constraint_exclusion参数来过滤不需要访问的分区。

功能测试

创建分区表

postgres=# create table t (id int, info text) partition by range (id);  
CREATE TABLE  
  
postgres=# create table t0 PARTITION OF t for values from (0) to (100);  
CREATE TABLE  
postgres=# create table t1 PARTITION OF t for values from (100) to (200);  
CREATE TABLE  
AI 代码解读

开启edb_enable_pruning参数,关闭constraint_exclusion参数

postgres=# show edb_enable_pruning ;  
 edb_enable_pruning   
--------------------  
 on  
(1 row)  
  
postgres=# set constraint_exclusion =off;  
SET  
AI 代码解读

简单SQL,可以看到edb_enable_pruning起作用了,过滤了不需要访问的分区。

postgres=# explain select * from t where id=1;  
                        QUERY PLAN                          
----------------------------------------------------------  
 Append  (cost=0.00..25.88 rows=6 width=36)  
   ->  Seq Scan on t0  (cost=0.00..25.88 rows=6 width=36)  
         Filter: (id = 1)  
(3 rows)  
AI 代码解读

但是对于非常量,无法优化,没有起到过滤效果。

postgres=# explain select * from t where id=1+1;  
                        QUERY PLAN                          
----------------------------------------------------------  
 Append  (cost=0.00..51.75 rows=12 width=36)  
   ->  Seq Scan on t0  (cost=0.00..25.88 rows=6 width=36)  
         Filter: (id = 2)  
   ->  Seq Scan on t1  (cost=0.00..25.88 rows=6 width=36)  
         Filter: (id = 2)  
(5 rows)  
AI 代码解读

打开 constraint_exclusion 参数,它会对复杂SQL进行过滤(仅限于immutable、stable的函数和操作符。)

postgres=# set constraint_exclusion =on;  
SET  
postgres=# explain select * from t where id=1+1;  
                        QUERY PLAN                          
----------------------------------------------------------  
 Append  (cost=0.00..25.88 rows=6 width=36)  
   ->  Seq Scan on t0  (cost=0.00..25.88 rows=6 width=36)  
         Filter: (id = 2)  
(3 rows)  
AI 代码解读

将edb_enable_pruning关闭,过滤不受影响。只是没有起到优化效果。

postgres=# set edb_enable_pruning =off;  
SET  
postgres=# explain select * from t where id=1+1;  
                        QUERY PLAN                          
----------------------------------------------------------  
 Append  (cost=0.00..25.88 rows=6 width=36)  
   ->  Seq Scan on t0  (cost=0.00..25.88 rows=6 width=36)  
         Filter: (id = 2)  
(3 rows)  
  
postgres=# explain select * from t where id=1;  
                        QUERY PLAN                          
----------------------------------------------------------  
 Append  (cost=0.00..25.88 rows=6 width=36)  
   ->  Seq Scan on t0  (cost=0.00..25.88 rows=6 width=36)  
         Filter: (id = 1)  
(3 rows)  
AI 代码解读

性能测试

为了体现优化效果,加到2000个分区。

postgres=# do language plpgsql $$  
declare  
begin  
  for i in 2..2000 loop  
    execute 'create table t'||i||' PARTITION OF t for values from ('||200+i||') to ('||200+i+1||')';  
  end loop;  
end;  
$$;  
DO  
AI 代码解读

测试简单SQL(起到优化效果的SQL)

vi test.sql  
  
select * from t where id=1;  
AI 代码解读

TPS达到了100万。

pgbench -M prepared -n -r -P 1 -f ./test.sql -c 56 -j 56 -T 120  
progress: 1.0 s, 1031487.3 tps, lat 0.053 ms stddev 0.328  
progress: 2.0 s, 1098419.2 tps, lat 0.051 ms stddev 0.009  
progress: 3.0 s, 1075788.5 tps, lat 0.052 ms stddev 0.014  
progress: 4.0 s, 1090429.9 tps, lat 0.051 ms stddev 0.010  
progress: 5.0 s, 1091784.5 tps, lat 0.051 ms stddev 0.010  
progress: 6.0 s, 1084007.3 tps, lat 0.052 ms stddev 0.012  
progress: 7.0 s, 1094544.1 tps, lat 0.051 ms stddev 0.009  
AI 代码解读

测试不能优化的SQL,只能走传统的constraint_exclusion参数过滤的,性能下降到了1000多TPS

vi test.sql  
  
select * from t where id=1+1;  
AI 代码解读
pgbench -M prepared -n -r -P 1 -f ./test.sql -c 56 -j 56 -T 120  
progress: 1.0 s, 0.0 tps, lat -nan ms stddev -nan  
progress: 2.0 s, 412.2 tps, lat 247.149 ms stddev 591.770  
progress: 3.0 s, 1196.0 tps, lat 53.604 ms stddev 112.786  
progress: 4.0 s, 1198.0 tps, lat 46.672 ms stddev 5.575  
AI 代码解读

pg_pathman 的对比性能

pg_pathman实际上以前已经对比过,性能非常好。

《PostgreSQL 10 内置分区 vs pg_pathman perf profiling》

同样创建2000个分区,测试简单和不简单的查询。

postgres=# CREATE EXTENSION pg_pathman;      
CREATE EXTENSION      
      
postgres=# create table tbl_range(id int not null, info text, crt_time timestamp);      
CREATE TABLE      
      
postgres=# select create_range_partitions('tbl_range', 'id', 0, 100, 2000);      
 create_range_partitions       
-------------------------      
                    2000      
(1 row)  
  
  
postgres=# \d tbl_range  
                        Table "public.tbl_range"  
  Column  |            Type             | Collation | Nullable | Default   
----------+-----------------------------+-----------+----------+---------  
 id       | integer                     |           | not null |   
 info     | text                        |           |          |   
 crt_time | timestamp without time zone |           |          |   
Number of child tables: 2000 (Use \d+ to list them.)  
AI 代码解读

pg_pathman不依赖传统的constraint_exclusion参数,简单和不简单的SQL,都被过滤了。

postgres=# set constraint_exclusion =off;  
SET  
  
postgres=# explain select * from tbl_range where id=1;  
                            QUERY PLAN                               
-------------------------------------------------------------------  
 Append  (cost=0.00..24.12 rows=6 width=44)  
   ->  Seq Scan on tbl_range_1  (cost=0.00..24.12 rows=6 width=44)  
         Filter: (id = 1)  
(3 rows)  
  
postgres=# explain select * from tbl_range where id=1+1;  
                            QUERY PLAN                               
-------------------------------------------------------------------  
 Append  (cost=0.00..24.12 rows=6 width=44)  
   ->  Seq Scan on tbl_range_1  (cost=0.00..24.12 rows=6 width=44)  
         Filter: (id = 2)  
(3 rows)  
AI 代码解读

性能测试

pgbench -M prepared -n -r -P 1 -f ./test.sql -c 56 -j 56 -T 120  
  
  
-- 简单SQL  
  
progress: 3.0 s, 947237.9 tps, lat 0.059 ms stddev 0.010  
progress: 4.0 s, 949539.4 tps, lat 0.059 ms stddev 0.009  
progress: 5.0 s, 948459.0 tps, lat 0.059 ms stddev 0.010  
progress: 6.0 s, 947355.4 tps, lat 0.059 ms stddev 0.010  
progress: 7.0 s, 947789.2 tps, lat 0.059 ms stddev 0.010  
progress: 8.0 s, 949380.5 tps, lat 0.059 ms stddev 0.010  
progress: 9.0 s, 944190.6 tps, lat 0.059 ms stddev 0.023  
progress: 10.0 s, 947677.8 tps, lat 0.059 ms stddev 0.010  
  
-- 非简单SQL  
  
progress: 3.0 s, 951051.2 tps, lat 0.059 ms stddev 0.012  
progress: 4.0 s, 960237.6 tps, lat 0.058 ms stddev 0.010  
progress: 5.0 s, 961659.2 tps, lat 0.058 ms stddev 0.009  
progress: 6.0 s, 946538.5 tps, lat 0.059 ms stddev 0.012  
progress: 7.0 s, 956382.1 tps, lat 0.059 ms stddev 0.011  
progress: 8.0 s, 961674.0 tps, lat 0.058 ms stddev 0.009  
progress: 9.0 s, 957060.6 tps, lat 0.059 ms stddev 0.010  
progress: 10.0 s, 950707.1 tps, lat 0.059 ms stddev 0.013  
progress: 11.0 s, 955766.4 tps, lat 0.059 ms stddev 0.010  
AI 代码解读

pg_pathman对简单和非简单SQL的优化效果一样,都非常的好。

性能对比

分区特性 TPS
PPAS native分区 edb_enable_pruning=on 常量条件过滤 1031487
PPAS native分区 edb_enable_pruning=on 条件无法过滤 1196
PG pg_pathman分区 957060

小结

对于PPAS用户,建议能常量输入的,就使用常量输入,这样能够用到分区过滤的优化特性。(特别是在分区表非常多的情况下,优化效果非常明显)。

对于PG用户,使用pg_pathman作为分区组件,在分区很多的情况下,性能比native的分区好很多很多。

相关实践学习
使用PolarDB和ECS搭建门户网站
本场景主要介绍基于PolarDB和ECS实现搭建门户网站。
阿里云数据库产品家族及特性
阿里云智能数据库产品团队一直致力于不断健全产品体系,提升产品性能,打磨产品功能,从而帮助客户实现更加极致的弹性能力、具备更强的扩展能力、并利用云设施进一步降低企业成本。以云原生+分布式为核心技术抓手,打造以自研的在线事务型(OLTP)数据库Polar DB和在线分析型(OLAP)数据库Analytic DB为代表的新一代企业级云原生数据库产品体系, 结合NoSQL数据库、数据库生态工具、云原生智能化数据库管控平台,为阿里巴巴经济体以及各个行业的企业客户和开发者提供从公共云到混合云再到私有云的完整解决方案,提供基于云基础设施进行数据从处理、到存储、再到计算与分析的一体化解决方案。本节课带你了解阿里云数据库产品家族及特性。
目录
打赏
0
0
0
0
20695
分享
相关文章
云原生数据仓库产品使用合集之阿里云云原生数据仓库AnalyticDB PostgreSQL版的重分布时间主要取决的是什么
阿里云AnalyticDB提供了全面的数据导入、查询分析、数据管理、运维监控等功能,并通过扩展功能支持与AI平台集成、跨地域复制与联邦查询等高级应用场景,为企业构建实时、高效、可扩展的数据仓库解决方案。以下是对AnalyticDB产品使用合集的概述,包括数据导入、查询分析、数据管理、运维监控、扩展功能等方面。
阿里云云原生数据仓库 AnalyticDB PostgreSQL 版已完成和开源LLMOps平台Dify官方集成
近日,阿里云云原生数据仓库 AnalyticDB PostgreSQL 版已完成和开源LLMOps平台Dify官方集成。
开源云原生数据库PolarDB PostgreSQL 15兼容版本正式发布
PolarDB进行了深度的内核优化,从而实现以更低的成本提供商业数据库的性能。
PostgreSQL普通表转换成分区表
如何使用pg_rewrite扩展将普遍表转换成分区表
nacos 2.2.3版本 查看配置文件的历史版本的接口 是针对MySQL数据库的sql 改成postgresql后 sql语句报错 该怎么解决
在Nacos 2.2.3中切换到PostgreSQL后,执行配置文件历史版本分页查询出错,因`LIMIT 0, 10`语法不被PostgreSQL支持,需改为`LIMIT 10 OFFSET 0`。仅当存在历史版本时报错。解决方案是调整查询SQL以兼容PostgreSQL语法。
5倍性能提升,阿里云AnalyticDB PostgreSQL版新一代实时智能引擎重磅发布
2023 云栖大会上,AnalyticDB for PostgreSQL新一代实时智能引擎重磅发布,全自研计算和行列混存引擎较比开源Greenplum有5倍以上性能提升。AnalyticDB for PostgreSQL与通义大模型家族深度集成,推出一站式AIGC解决方案。阿里云新发布的行业模型及“百炼”平台,采用AnalyticDB for PostgreSQL作为内置向量检索引擎,性能较开源增强了2~5倍。大会上来自厦门国际银行、三七互娱等知名企业代表和瑶池数据库团队产品及技术资深专家们结合真实场景实践,深入分享了最新的技术进展和解析。
5倍性能提升,阿里云AnalyticDB PostgreSQL版新一代实时智能引擎重磅发布
上新|阿里云RDS PostgreSQL支持PG 16版本,AliPG提供丰富自研能力
AliPG在社区版16.0的基础上,在安全、成本、可运维性等多个方面做了提升,丰富的内核/插件特性支持,满足业务场景的需求
阿里云PolarDB是一款兼容MySQL、PostgreSQL和SQL Server等多种数据库协议的产品
阿里云PolarDB是一款兼容MySQL、PostgreSQL和SQL Server等多种数据库协议的产品
929 6

相关产品

  • 云原生数据库 PolarDB
  • 云数据库 RDS PostgreSQL 版
  • AI助理

    你好,我是AI助理

    可以解答问题、推荐解决方案等