PostgreSQL 12 首个版本说明草案发布

局长
 局长
发布于 2019年05月14日
收藏 19

虽然 PostgreSQL 12 尚未发布,不过开发团队已公布其首个版本说明草案。据官方介绍,这是一个十分重要的版本,下面看看有哪些值得关注的变化。

对于从任意旧版本迁移到 PostgreSQL 12 的用户,需要使用 pg_dumpall 或 pg_upgrade 进行 dump/restore(备份和恢复) 操作。

PostgreSQL 12 还包含许多可能影响与旧版本之间的兼容性的变更:

  • 删除系统列 OID 的某些特殊行为

    旧版本中,在创建表时可以通过WITH OIDS指定正常情况下不可见(normally-invisible)的 OID 列;在新版本中该特性已被删除,不过列仍可以被显式地指定为OID类型。

  • 删除数据类型abstimereltimetinterval

  • 删除时间段扩展(timetravel extension)

  • recovery.conf设置移动至postgresql.conf

    recovery.conf将不再被使用,如果该文件仍存在,服务器将无法启动。

  • 不再允许多种不同的recovery_target* 规范

    旧版本中,可指定多个不同的 recovery_target*变量,现在只能指定一个。

  • 导致需要恢复的情况将默认使用最新状态

    具体来说,recovery_target_time现在的默认值为latest,而旧版本的默认值为current

  • 重构几何函数和运算符

    会使得结果更准确,但和旧版本相比略有不同

  • 重构几何类型以更加一致地处理 NaN、下溢、上溢和除零情况

  • 改进社区报告的针对行数据类型的行为和错误

分区方面也有不少的改进:

  • 提高分区表上许多操作的性能

    现在可以有效地对数以千计的分区进行修剪

  • 允许外键引用分区表

  • 提高COPY分区表的速度

  • 允许将分区边界设置为任意表达式

  • 允许CREATE TABLE分区表的表空间规范影响其子表空间

此外还有索引、认证、监控和功能优化等诸多变化。由于内容十分多,建议直接查看原文

本站文章除注明转载外,均为本站原创或编译。欢迎任何形式的转载,但请务必注明出处,尊重他人劳动共创开源社区。
转载请注明:文章转载自 OSCHINA 社区 [http://www.oschina.net]
本文标题:PostgreSQL 12 首个版本说明草案发布
加载中

精彩评论

s
shifeng1983

引用来自“霡霂”的评论

关系数据库还是转向New SQL 才是未来。

引用来自“冰力”的评论

@霡霂 很多场景转不了,而且更多场景根本没必要转。

引用来自“霡霂”的评论

那就看这个产品的支持力度了,比如TIDB,MySQL兼容做的非常好,如果是一个小项目,在语法用法层面,感觉不到区别。如果幸运的摊上一个大项目,那点兼容性的问题,先不说会不会遇到兼容性问题,真遇到了也不是个事,总比折腾一堆分库分表或者、高可用的中间件轻松。不过TiDB的硬件要求有点高,CockroachDB就比较皮实了,你完全可以用一堆树莓派搭建一个非常稳定可靠的高性能的存储集群。
CAP理论就让你这么给突破了?
霡霂
霡霂

引用来自“霡霂”的评论

关系数据库还是转向New SQL 才是未来。

引用来自“冰力”的评论

@霡霂 很多场景转不了,而且更多场景根本没必要转。
那就看这个产品的支持力度了,比如TIDB,MySQL兼容做的非常好,如果是一个小项目,在语法用法层面,感觉不到区别。如果幸运的摊上一个大项目,那点兼容性的问题,先不说会不会遇到兼容性问题,真遇到了也不是个事,总比折腾一堆分库分表或者、高可用的中间件轻松。不过TiDB的硬件要求有点高,CockroachDB就比较皮实了,你完全可以用一堆树莓派搭建一个非常稳定可靠的高性能的存储集群。
一号男嘉宾
一号男嘉宾
PG大法好
朝半仙
朝半仙

引用来自“霡霂”的评论

关系数据库还是转向New SQL 才是未来。
new SQL是什么?
霡霂
霡霂

引用来自“霡霂”的评论

关系数据库还是转向New SQL 才是未来。

引用来自“朝半仙”的评论

new SQL是什么?
对关系型数据库的重新定义。原生的、透明支持分布式和高可用。不在再产品中引入一堆切分的中间件。参见TIDB、CockroachDB、Greenplum。

最新评论(21

左华栋
左华栋

引用来自“霡霂”的评论

关系数据库还是转向New SQL 才是未来。

引用来自“代码之美”的评论

看到你的大放厥词,花了半个小时了解new sql是个什么玩意儿,业界定义为“分布式关系型数据库”,解决的痛点是传统关系型数据库主从,多主复杂困难的问题。不管是分布式关系型数据库new sql还是键值型数据库nosql,其都是在特定应用场景下的产物,一个用于弱数据环境,一个用于大规模数据环境,你给我说“转向”,不怕闪掉大牙。

引用来自“霡霂”的评论

我们只是技术讨论,你要有什么情绪回家对着你家人撸去,这里没人惯着你。

引用来自“代码之美”的评论

没看到你有任何支持你的惊人结论的论据,就一句话扔这了,这算哪门子讨论,哗众取宠吗

引用来自“霡霂”的评论

又不是辩论大赛,赢了没有奖金,没有奖品,我至于见了人就解释一遍吗?另外对于new sql,你真的理解偏了。如果你针对new sql真的感兴趣,就好好看看TiDB,CockroachDB的特性和功能。支不支持分布式,与nosql的应用领域关系不大。new sql出现的根本原因还是RMDB数据库的sharding中间件在实际应用中糟糕的表现。当我们不得不使用分布式解决性能问题的时候要面临以下几个挑战:
1、如何在实现分布式的同时,减少对业务的影响:对于业务来说,是分布式是透明的(少修改代码,甚至不修改代码,SQL还是SQL);
2、如何在实现分布式的同时,我如何能做到高可用,(异地)容灾和恢复;
3、如何在实现分布式的同时,自由的对数据进行伸缩操作(随时增加服务器节点扩容,而不是担心数据的分布问题);
4、如何在实现分布式的同时,继续使用事物,以及保证数据一致性;
5、如何在实现分布式的同时,即可以OLTP,又可以OLAP(传统架构上,OLAP需要建立一个单独的数据仓库)
6、如何在实现分布式的同时,以上过程尽可能的简单化,更容易实现自动化。
从初衷看,new sql是对传统RMDB的改良,大家仍需要RMDB,也想要一个真正简洁可靠的分布式。从长远看,传统的RMDB 更像是New SQL的一个特殊状态,即单节点,上面提到的TIDB和CockroachDB都可以在单节点下运行,而且TIDB兼容MySQL协议,CockroachDB兼容PgSQL,甚至他们的驱动和管理工具可以直接拿来用。
上面提到的两个new sql底层实现上,确实是基于KV存储的(NoSQL),但是对于用户来说接触不到,用户仍然是使用sql。如果说非要说和nosql沾边的话,两者都支持json类型和操作,就像MySQL5.7和PgSQL9.2.0中增加对json的支持一样。
postgresql 支持的 jsonb 更加Nosql 。 mysql 的 json 算不上~
霡霂
霡霂

引用来自“霡霂”的评论

关系数据库还是转向New SQL 才是未来。

引用来自“代码之美”的评论

看到你的大放厥词,花了半个小时了解new sql是个什么玩意儿,业界定义为“分布式关系型数据库”,解决的痛点是传统关系型数据库主从,多主复杂困难的问题。不管是分布式关系型数据库new sql还是键值型数据库nosql,其都是在特定应用场景下的产物,一个用于弱数据环境,一个用于大规模数据环境,你给我说“转向”,不怕闪掉大牙。

引用来自“霡霂”的评论

我们只是技术讨论,你要有什么情绪回家对着你家人撸去,这里没人惯着你。

引用来自“代码之美”的评论

没看到你有任何支持你的惊人结论的论据,就一句话扔这了,这算哪门子讨论,哗众取宠吗
又不是辩论大赛,赢了没有奖金,没有奖品,我至于见了人就解释一遍吗?另外对于new sql,你真的理解偏了。如果你针对new sql真的感兴趣,就好好看看TiDB,CockroachDB的特性和功能。支不支持分布式,与nosql的应用领域关系不大。new sql出现的根本原因还是RMDB数据库的sharding中间件在实际应用中糟糕的表现。当我们不得不使用分布式解决性能问题的时候要面临以下几个挑战:
1、如何在实现分布式的同时,减少对业务的影响:对于业务来说,是分布式是透明的(少修改代码,甚至不修改代码,SQL还是SQL);
2、如何在实现分布式的同时,我如何能做到高可用,(异地)容灾和恢复;
3、如何在实现分布式的同时,自由的对数据进行伸缩操作(随时增加服务器节点扩容,而不是担心数据的分布问题);
4、如何在实现分布式的同时,继续使用事物,以及保证数据一致性;
5、如何在实现分布式的同时,即可以OLTP,又可以OLAP(传统架构上,OLAP需要建立一个单独的数据仓库)
6、如何在实现分布式的同时,以上过程尽可能的简单化,更容易实现自动化。
从初衷看,new sql是对传统RMDB的改良,大家仍需要RMDB,也想要一个真正简洁可靠的分布式。从长远看,传统的RMDB 更像是New SQL的一个特殊状态,即单节点,上面提到的TIDB和CockroachDB都可以在单节点下运行,而且TIDB兼容MySQL协议,CockroachDB兼容PgSQL,甚至他们的驱动和管理工具可以直接拿来用。
上面提到的两个new sql底层实现上,确实是基于KV存储的(NoSQL),但是对于用户来说接触不到,用户仍然是使用sql。如果说非要说和nosql沾边的话,两者都支持json类型和操作,就像MySQL5.7和PgSQL9.2.0中增加对json的支持一样。
代码之美
代码之美

引用来自“霡霂”的评论

关系数据库还是转向New SQL 才是未来。

引用来自“代码之美”的评论

看到你的大放厥词,花了半个小时了解new sql是个什么玩意儿,业界定义为“分布式关系型数据库”,解决的痛点是传统关系型数据库主从,多主复杂困难的问题。不管是分布式关系型数据库new sql还是键值型数据库nosql,其都是在特定应用场景下的产物,一个用于弱数据环境,一个用于大规模数据环境,你给我说“转向”,不怕闪掉大牙。

引用来自“霡霂”的评论

我们只是技术讨论,你要有什么情绪回家对着你家人撸去,这里没人惯着你。
new sql的竞争对像更多是mongodb之类的分布式数据库,跟pg八杆子打不着
代码之美
代码之美

引用来自“霡霂”的评论

关系数据库还是转向New SQL 才是未来。

引用来自“代码之美”的评论

看到你的大放厥词,花了半个小时了解new sql是个什么玩意儿,业界定义为“分布式关系型数据库”,解决的痛点是传统关系型数据库主从,多主复杂困难的问题。不管是分布式关系型数据库new sql还是键值型数据库nosql,其都是在特定应用场景下的产物,一个用于弱数据环境,一个用于大规模数据环境,你给我说“转向”,不怕闪掉大牙。

引用来自“霡霂”的评论

我们只是技术讨论,你要有什么情绪回家对着你家人撸去,这里没人惯着你。
没看到你有任何支持你的惊人结论的论据,就一句话扔这了,这算哪门子讨论,哗众取宠吗
霡霂
霡霂

引用来自“霡霂”的评论

关系数据库还是转向New SQL 才是未来。

引用来自“代码之美”的评论

看到你的大放厥词,花了半个小时了解new sql是个什么玩意儿,业界定义为“分布式关系型数据库”,解决的痛点是传统关系型数据库主从,多主复杂困难的问题。不管是分布式关系型数据库new sql还是键值型数据库nosql,其都是在特定应用场景下的产物,一个用于弱数据环境,一个用于大规模数据环境,你给我说“转向”,不怕闪掉大牙。
我们只是技术讨论,你要有什么情绪回家对着你家人撸去,这里没人惯着你。
代码之美
代码之美

引用来自“霡霂”的评论

关系数据库还是转向New SQL 才是未来。
看到你的大放厥词,花了半个小时了解new sql是个什么玩意儿,业界定义为“分布式关系型数据库”,解决的痛点是传统关系型数据库主从,多主复杂困难的问题。不管是分布式关系型数据库new sql还是键值型数据库nosql,其都是在特定应用场景下的产物,一个用于弱数据环境,一个用于大规模数据环境,你给我说“转向”,不怕闪掉大牙。
witt-xy
witt-xy
PG真香
renwofei423
renwofei423

引用来自“一号男嘉宾”的评论

PG大法好
听说删除了简体中午还是中国地区?
霡霂
霡霂

引用来自“霡霂”的评论

关系数据库还是转向New SQL 才是未来。

引用来自“冰力”的评论

@霡霂 很多场景转不了,而且更多场景根本没必要转。

引用来自“霡霂”的评论

那就看这个产品的支持力度了,比如TIDB,MySQL兼容做的非常好,如果是一个小项目,在语法用法层面,感觉不到区别。如果幸运的摊上一个大项目,那点兼容性的问题,先不说会不会遇到兼容性问题,真遇到了也不是个事,总比折腾一堆分库分表或者、高可用的中间件轻松。不过TiDB的硬件要求有点高,CockroachDB就比较皮实了,你完全可以用一堆树莓派搭建一个非常稳定可靠的高性能的存储集群。

引用来自“shifeng1983”的评论

CAP理论就让你这么给突破了?

引用来自“霡霂”的评论

没get到我说的和cap哪里冲突了,还请指明,感谢。

引用来自“shifeng1983”的评论

分布式的主要问题就是慢,时间都消耗在网络传输上了,如果用一堆树莓派能解决的问题,那用电脑单机一定也能解决。好的做法是业务拆分一下,或者用异构数据库,基本上能解决99%的问题,
你理解错了。“可以用一堆树莓派搭建一个非常稳定可靠的高性能的存储集群”这句话是用来表达TiDB对硬件要求高。另外,无论是TiDB、还是CockroachDB、或者Greenplum,亦或是google的spanner,都不是强一致性(那是传统关系数据库的强项),而是采用的最终一致性,只要是最终一致性,没有不出现数据延迟的。但是最终一致性并不违反cap理论,而是cap理论阐述的一部分。另外虽然性能很重要,但不是性能并不是考察分布式系统的唯一指标。
10个树莓派节点的吞吐量可能比不上一台服务器,但是100个节点呢?一台单机,宕机后就无法提供服务了,但是对于100个树莓派节点的CockroachBD集群来说,即便宕机一半(50个节点),仍然可以提供服务,哪怕这50个树莓派的硬盘完全被损坏,集群中的数据仍然不会丢失(一条数据记录在CockrochDB集群中至少有3个数据副本,分布在不同的节点上),假如说,100个节点仍然不能满足性能需求,或者存储量不足,直接增加新的节点,由集群自动的对数据进行分布,创建副本等(水平可伸缩性)。
真遇到了单机性能问题,业务拆分或者使用异构数据库,并不能真的解决问题,分布式(sharding)和集群是绕不过的坎。无论你是将业务拆分到不同的数据库中(垂直切分),还是对业务量大的数据表进行分片(水平切分),都需要对项目本身的架构进行大的调整,以应对分布式事务和数据切分的难题,但是使用NewSQL,这些都不是问题,简单说,你可以像写单机应用一样完成一个分布式系统的开发。不过CockroachDB等面对的业务场景,更多的是微服务、大数据量、高负载的场景。
s
shifeng1983

引用来自“霡霂”的评论

关系数据库还是转向New SQL 才是未来。

引用来自“冰力”的评论

@霡霂 很多场景转不了,而且更多场景根本没必要转。

引用来自“霡霂”的评论

那就看这个产品的支持力度了,比如TIDB,MySQL兼容做的非常好,如果是一个小项目,在语法用法层面,感觉不到区别。如果幸运的摊上一个大项目,那点兼容性的问题,先不说会不会遇到兼容性问题,真遇到了也不是个事,总比折腾一堆分库分表或者、高可用的中间件轻松。不过TiDB的硬件要求有点高,CockroachDB就比较皮实了,你完全可以用一堆树莓派搭建一个非常稳定可靠的高性能的存储集群。

引用来自“shifeng1983”的评论

CAP理论就让你这么给突破了?

引用来自“霡霂”的评论

没get到我说的和cap哪里冲突了,还请指明,感谢。
分布式的主要问题就是慢,时间都消耗在网络传输上了,如果用一堆树莓派能解决的问题,那用电脑单机一定也能解决。好的做法是业务拆分一下,或者用异构数据库,基本上能解决99%的问题,
返回顶部
顶部