PostgreSQL 10.0 preview 功能增强 - 分区表(list default)

简介:

标签

PostgreSQL , 10.0 , 分区表 , 默认分区


背景

PostgreSQL 10.0将支持range,list分区表,同时hash分区处于POC阶段(同时还有一些需要改进的地方,例如优化器部分)。

如果你使用的是10.0以前的版本,可以使用pg_pathman插件实现分区,pg_pathman已经非常的完美。

PostgreSQL支持伪表作为分区,例如外部表,物化视图。伪表作为分区有很多可以适合的使用场景,例如将外部表作为分区,则可以实现sharding场景。

分区表用法

https://www.postgresql.org/docs/devel/static/sql-createtable.html

《PostgreSQL 10.0 内置分区表》

同时list分区将添加default语法,没有在list中的数据,将写入default分区。

Hello,  

Currently inserting the data into a partitioned table that does not fit into  
any of its partitions is not allowed.  

The attached patch provides a capability to add a default partition to a  
list  
partitioned table as follows.  

postgres=# CREATE TABLE list_partitioned (  
    a int  
) PARTITION BY LIST (a);  
CREATE TABLE  

postgres=# CREATE TABLE part_default PARTITION OF list_partitioned FOR  
VALUES IN (DEFAULT);  
CREATE TABLE  

postgres=# CREATE TABLE part_1 PARTITION OF list_partitioned FOR VALUES IN  
(4,5);  
CREATE TABLE  

postgres=# insert into list_partitioned values (9);  
INSERT 0 1  

postgres=# select * from part_default;  
 a  
---  
 9  
(1 row)  

The attached patch is in a  preliminary stage and has following ToDos:  
1. Adding pg_dump support.  
2. Documentation  
3. Handling adding a new partition to a partitioned table  
   with default partition.  
   This will require moving tuples from existing default partition to  
  newly created partition if they satisfy its partition bound.  
4. Handling of update of partition key in a default partition. As per  
current design it should throw an error if the update requires the tuple to  
be moved to any other partition. But this can changed by the following  
proposal.  

https://www.postgresql.org/message-id/CAJ3gD9do9o2ccQ7j7+tSgiE1REY65XRiMb=  
yJO3u3QhyP8EEPQ(at)mail(dot)gmail(dot)com  

I am adding it to the current commitfest with the status Waiting on Author  
as I will submit an updated patch with above ToDos.  
Kindly give your suggestions.  

Thank you,  
Rahila Syed  

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

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

参考

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

https://www.postgresql.org/message-id/flat/CAH2L28tbN4SYyhS7YV1YBWcitkqbhSWfQCy0G=apRcC_PEO-bg@mail.gmail.com#CAH2L28tbN4SYyhS7YV1YBWcitkqbhSWfQCy0G=apRcC_PEO-bg@mail.gmail.com

相关实践学习
使用PolarDB和ECS搭建门户网站
本场景主要介绍如何基于PolarDB和ECS实现搭建门户网站。
阿里云数据库产品家族及特性
阿里云智能数据库产品团队一直致力于不断健全产品体系,提升产品性能,打磨产品功能,从而帮助客户实现更加极致的弹性能力、具备更强的扩展能力、并利用云设施进一步降低企业成本。以云原生+分布式为核心技术抓手,打造以自研的在线事务型(OLTP)数据库Polar DB和在线分析型(OLAP)数据库Analytic DB为代表的新一代企业级云原生数据库产品体系, 结合NoSQL数据库、数据库生态工具、云原生智能化数据库管控平台,为阿里巴巴经济体以及各个行业的企业客户和开发者提供从公共云到混合云再到私有云的完整解决方案,提供基于云基础设施进行数据从处理、到存储、再到计算与分析的一体化解决方案。本节课带你了解阿里云数据库产品家族及特性。
目录
相关文章
|
SQL 关系型数据库 数据库
PostgreSQL数据库报错 ERROR: multiple default values specified for column "" of table "" 如何解决?
PostgreSQL数据库报错 ERROR: multiple default values specified for column "" of table "" 如何解决?
909 59
|
SQL 弹性计算 关系型数据库
PostgreSQL 12 preview - CTE 增强,支持用户语法层控制 materialized 优化
标签 PostgreSQL , CTE , materialized , not materialized , push down 背景 PostgreSQL with 语法,能跑非常复杂的SQL逻辑,包括递归,多语句物化计算等。 在12以前的版本中,WITH中的每一个CTE(common table express),都是直接进行物化的,也就是说外层的条件不会推到CTE(物化节点)里
1286 0
|
弹性计算 关系型数据库 数据库连接
PostgreSQL 12 preview - Move max_wal_senders out of max_connections for connection slot handling
标签 PostgreSQL , max_wal_senders , max_connections , sorry, too many clients already 背景 如果你需要使用PG的流复制,上游节点的max_wal_senders参数,用来限制这个节点同时最多可以有多少个wal sender进程。 包括逻辑复制、物理复制、pg_basebackup备份等,只要是使用stre
480 0
|
弹性计算 安全 关系型数据库
PostgreSQL 12 preview - 可靠性提升 - data_sync_retry 消除os层write back failed status不可靠的问题
标签 PostgreSQL , data_sync_retry , write back , retry , failed status 背景 有些OS系统,对fsync的二次调用不敏感,因为OS层可能有自己的CACHE,如果使用了buffer write,并且出现write back failed的情况,有些OS可能在下次fsync时并不能正确的反馈fsync的可靠性与否。(因为这个B
683 0
|
SQL 弹性计算 Oracle
PostgreSQL native partition 分区表性能优化之 - 动态SQL+服务端绑定变量
标签 PostgreSQL , 分区表 , native partition , 性能 , pg_pathman , plpgsql , 动态SQL , 服务端绑定变量 , prepare , execute 背景 目前PG的native partition分区性能不佳,一种解决方法是使用pg_pathman插件,另一种方法是业务上直接插分区,还有一种方法是使用UDF函数接口(函数内部使
1549 0
|
SQL 关系型数据库 测试技术
PostgreSQL pgbench tpcb 海量数据库测试 - 分区表测试优化
标签 PostgreSQL , pgbench , tpcb 背景 pgbench是PG的一款测试工具,内置的测试CASE为tpcb测试。同时支持用户自己写测试CASE。 大量自定义CASE参考 https://github.com/digoal/blog/blob/master/201711/readme.md 当我们使用tpcb测试CASE时,如果生成的数据量过于庞大,例如我最近在生成1万亿的CASE,可以考虑使用分区表,但是目前PG内置分区表的性能在分区非常多时,使用PREPARED STATEMENT会导致性能下降。
2106 0
|
SQL Oracle 算法
PostgreSQL 12 preview - plan_cache_mode参数控制强制使用plan cache或强制custom plan (force_custom_plan and force_generic_plan)
标签 PostgreSQL , plan_cache_mode 背景 plan cache在OLTP中,可以大幅降低生成sql parser, 执行计划的开销。 但是在某些场景中,plan cache可能成为问题,比如AP类型的场景中,由于SQL 输入条件的变化(通常AP业务涉及的条件可能比较容易出现这样的问题),可能导致plan cache并不是最佳的执行计划。
1670 0
|
6月前
|
存储 关系型数据库 测试技术
拯救海量数据:PostgreSQL分区表性能优化实战手册(附压测对比)
本文深入解析PostgreSQL分区表的核心原理与优化策略,涵盖性能痛点、实战案例及压测对比。首先阐述分区表作为继承表+路由规则的逻辑封装,分析分区裁剪失效、全局索引膨胀和VACUUM堆积三大性能杀手,并通过电商订单表崩溃事件说明旧分区维护的重要性。接着提出四维设计法优化分区策略,包括时间范围分区黄金法则与自动化维护体系。同时对比局部索引与全局索引性能,展示后者在特定场景下的优势。进一步探讨并行查询优化、冷热数据分层存储及故障复盘,解决分区锁竞争问题。
821 2
|
关系型数据库 分布式数据库 PolarDB
《阿里云产品手册2022-2023 版》——PolarDB for PostgreSQL
《阿里云产品手册2022-2023 版》——PolarDB for PostgreSQL
562 0

相关产品

  • 云原生数据库 PolarDB
  • 云数据库 RDS PostgreSQL 版
  • 推荐镜像

    更多