共计 4010 个字符，预计需要花费 11 分钟才能阅读完成。
本篇内容介绍了“PostgreSQL 12 GA 的新特性有哪些”的有关知识，在实际案例的操作过程中，不少人都会遇到这样的困境，接下来就让丸趣 TV 小编带领大家学习一下如何处理这些情况吧！希望大家仔细阅读，能够学有所成！
SQL 的执行优化
第一个重要的变更：重建索引的并行化处理。 比如在遇到索引数据损坏、索引膨胀、索引的创建选项变更、无效索引重建等情况，在之前版本中，重建索引需要在表上加全局只读锁，阻止其他会话的写入。而在现在，则通过一个细分的多步事务操作，避免了这个问题，具体如下： 1. 首先，是开启事务，创建临时索引。2. 在临时索引上开始插入数据，这里需要注意的是，如果是重建表上的所有索引，那么这里也会同时创建对应数量的临时索引。3. 当前一步插入数据完成，再插入创建索引期间产生的新的数据。4. 所有数据都插入完毕后，使用临时缩影替换掉原先的索引。5. 最后删除老索引完成整体操作。 第二个重要的变更：生成列功能的加入。 在数据库的使用中，难免会遇到需要的数据库表的某一列或者某几列使用函数生成的数据。这种时候，如果每次都是实时地进行运算，那么这个计算代价比较大，尤其是表非常大的时候。 生成列的出现就是为了解决这个问题。每当数据插入数据库表的时候，对于生成列来说，就会生成其对应的数据，而不需要用户的明确输入，当然实际上用户也无法输入。 在 PG 的实现里面，包含了对生成列的索引的处理。 但是目前这个功能的实现也不是万能的，它存在很多的限制。下面我列出其中一些： 1. 目前只能实现某一行的计算。2. 不支持子查询。3. 不能使用别的生成列。4. 能用作分区键。 第三个重要的变更：优化器层面的处理，即 CTE 的 inline 优化。 CTE，实际上指的就是 with 语法指定的在主 SQL 语句前面的查询，通常会作为临时表提供给主查询结构使用。 在之前的实现形态中，执行时候会首先查询出来 CTE 内的数据作为临时表，然后去对执行主查询对应的操作，而在 PostgreSQL 12 中，这里进行了名为 inline 的优化：如果 ctw 表达式指定的表，在主查询中制备使用了一次，那么，数据库会直接使用子查询，而非预先查询的方式来执行之后的查询与处理，这里与 c 等编程语言的 inline 意味类似。 通过子查询进行进一步的优化，可以很大程度地提升性能。 这个特性也可以人工控制，对于一些不满足条件的 CTE 也进行 inline 处理（MATERIALIZED），或者对满足条件的情况下，依然不使用 inline 方式处理（NOT MATERIALIZED）。 第四个重要的变更：缓存执行计划，目前虽然未见得有多么重要，但在未来，可能会有很大作用的一个功能。 众所周知，Oracle 是缓存执行计划的，而类似 MySQL，PostgreSQL 这些开源数据库，都是 SQL 语句每次现场解析来处理的。而现在，PostgreSQL 12 中，首先做到了执行计划的缓存———虽然这个功能影响范围目前十分有限：目前只有明确使用了 prepare 语句，创建了临时过程，或者干脆就是存储过程 PL/pgSQL，否则无法使用到缓存的执行计划，远远达不到像 Oracle 那样，普通 SQL 语句都可以缓存执行计划。 但是，可以展望的未来，就势必会有这么一个优化。而这，也将是后续 PG 的迭代版本需要去做到的事情。 第五个重要的变更：实际上是配置的变更，但其主题影响的是 SQL 执行，因此在这里简单说一下，就是 JIT 在 PostgreSQL 12 中，默认是打开的状态。 关于 JIT，在这里简单描述一下：把 SQL 语句中的简单计算，直接编译为机器汇编码执行，效率远高于需要从 SQL 转 C 调用的普通 SQL 执行效率，除了需要在 SQL 解析阶段稍微多一点 CPU 之外，没有其他坏处，而打开这个特性，获得的好处是巨大的。配置的优化除了 SQL 优化这个开发人员最关心的话题之外，对于运维来说，PG 12 这个版本也做到很多的变化。 第一个，是新增了两个管理用的视图，以及一个新的函数：- pg_stat_progress_create_index 查看当前正在创建的索引进度
已经执行的数据块数量
已经执行的行数量
使用 / 等待锁的情况
– pg_stat_progress_cluster 查看当前 vacuum full/cluster 进度
数据块读写数量
数据条目读写数量
– pg_ls_archive_statusdir() 列出归档状态文件夹内容 这个变化让 DBA 可以对数据库中发生的重度行为有更详细的了解，以下定更好的决策。 第二个，是我认为绝对值得大书一笔，在 PG 历史上留下精彩篇章的变更：“干掉”recovery.conf 文件，配置项目合并入 postgresql.conf 配置文件。 这个文件几乎伴随着 PG 的出现就已经存在了，在 PG 9.0 版本之前漫长的年代，这个文件负责了 redo（WAL/XLOG）的回放配置，因此叫做 recovery.conf。在 9.0 之后，流复制出现，于是理所当然地，流复制的配置，也被放到这个文件里面了。而后，实际上这个文件更多地扮演者流复制配置而非数据恢复的角色。但是，与数据恢复仅仅需要离线操作不同，流复制在很多时候，是需要有在线变更手段的，而 recovery.conf 不支持 reload，就成了一个需要解决的麻烦事了。 在 PostgreSQL 开始，这个文件原先的项目合并到 postgresql.conf 之后，为了避免配置冲突，PG 自己新增了一个强行的限制：如果检查到数据目录有 recovery.conf 这个文件，则不允许数据库启动。 这个合并，不仅仅是个单纯的合并，也牵扯到很多相关参数的改名以及默认值变更： – 以下参数允许 reload
archive_cleanup_command
promote_trigger_file
recovery_end_command
recovery_min_apply_delay
– 名称与默认值变更
trigger_file 名称变更为 promote_trigger_file
取消 standby_mode 配置选项
不允许指定多个 recovery target
默认恢复到 last 时间线（之前是 current）
使用 cluster name 作为默认的 wal receiver 的 application name
相信未来的后续版本，PG 主从切换之后，standby 不需要重启就可以变更主库，也不是一件不可能的事情了。 第三个，是 PG 的日常问题，vacuum 的优化：
设置 VACUUM 不回收尾部空白页
设置 VACUUM 跳过对索引的扫描
设置 VACUUM 遇到无法立即获取的锁则跳过
这些设置当然可以极大程度地减小 vacuum 对数据库的影响，但对 PG 的未来来说，更好地解决这个问题的方式，当然是新的存储引擎。独立存储引擎就实际来说，MySQL 早些年的 MyISAM，实现质量并不好，不支持事务，表级别的读写锁。但因为存储引擎独立接口，MySQL 等到了 InnoDB，InnoDB 实现了全套事务存储引擎，且现在已完全取代了 MyISAM 的地位。 而 PG 本身就实现了事务存储引擎，这个独立存储引擎的需求虽然很多年前早已规划，但实际上拆分出来正经去做，才是这个迭代的事情。 目前，PG 单独处理了数据存储，索引存储的接口，第三方可以直接实现对应的接口和数据结构，就可以让 PG 利用到新增的存储引擎。 在社区里，已经有两个非常重要的存储引擎产生 – 虽然距离生成环境尚且还有一段距离，但这两个存储引擎都解决了 PG 本身存在多年的痼疾，未来可期。 两个非常重要的存储引擎，就是 EDB 的 zheap（开发中），以及 Greenplum 团队共享的 zedstore（开发中）存储引擎。 首先，说一说 zheap。 PostgreSQL 的存储实现中，其中 dirty 的一部分，vacuum，在实际生产环境中，成了一个每个运维都必须面对的问题。在 zheap 中，通过引入 undo 日志，zheap 试图同时解决 vacuum 问题，以及 32 位事务 id 导致的 vacuum freeze（事务 ID 回卷）问题。 在 zheap 中，并没有对 heap（后文以此代称“pg”原生存储引擎）的索引，执行计划等进行处理，而只是单纯处理了其数据存储部分，也就是把 undo 从数据文件剥离出来成为 undo 日志。 目前其实现是：undo 日志一直向前写（类似 WAL 日志），单独的 purge 进程从 undo 日志最老的日志开始回收，数据变更会保留在 undo 日志的数据指针，方便需要查询“老”数据的情况。这么一来，就可以避免数据文件的膨胀，以及 vacuum 的全表扫描的代价了。 而 zedstore 则代表了不同的方向：OLAP。greenplum 所处理的，就是 MPP 数据仓库，而在数据仓库来说，通常扫描一个表特定几列的情况，会远多于需要同时扫所有列的情况，因此 zedstore 设计目的，就是一个列存数据库。 zedstore 的实现中，每个条目，都有一个名为 tid 的虚拟主键，表的某一列或者某几列，就保存在使用 tid 作为主键的 B 树索引中。通过支持 tid 到多列的索引，也相当于实现了“行列混合存储”。 zedstore 另外一个重要的实现，就是压缩。zedstore 数据存储的时候，是只压缩数据，不压缩数据块元数据的，这么搞虽然牺牲了一定比例的压缩比（考虑到数据块头的大小，未必有多大代价）。但得到的好处就是显而易见了：数据块以压缩的形态存储在共享池中，由用户会话解压缩各自所需的数据 – 作为对比的 MySQL InnoDB 压缩，就是整个数据块级别的压缩，于是共享池里面，就得同时保存数据块的压缩与未压缩版本，平白消耗了宝贵的内存。
“PostgreSQL 12 GA 的新特性有哪些”的内容就介绍到这里了，感谢大家的阅读。如果想了解更多行业相关的知识可以关注丸趣 TV 网站，丸趣 TV 小编将为大家输出更多高质量的实用文章！
