PostgreSQL 10.0 preview 性能增强 - pg_xact align(cacheline对齐)

标签

PostgreSQL , 10.0 , cacheline对齐 , pgxact


背景

cacheline对齐,可以大幅提升高并发下的性能。

Hackers,  

originally this idea was proposed by Andres Freund while experimenting with
lockfree Pin/UnpinBuffer [1].
The patch is attached as well as results of pgbench -S on 72-cores
machine.  As before it shows huge benefit in this case.
For sure, we should validate that it doesn't cause performance regression
in other cases.  At least we should test read-write and smaller machines.
Any other ideas?  

1.
https://www.postgresql.org/message-id/20160411214029.ce3fw6zxim5k6a2r@alap3.anarazel.de  

------
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company

测试

I already had the results with both the patches applied. But, as I was not
quite
able to understand on how Simon's patch for reducing pgxact access could
negate the regression on read-write workload that we saw with pgxact-align-3
patch earlier, I was slightly hesitant to share the results. Anyways, here
are
the results with combined patches on readonly and readwrite workload:

1) Results for read-only workload:
========================
pgbench -i -s 300 postgres
pgbench -M prepared -c $thread -j $thread -T $time_for_reading -S postgres

where, time_for_reading = 10mins
*non default param:*
shared_buffers=8GB
max_connections=300

CLIENT COUNT TPS (HEAD) TPS (PATCH) % IMPROVEMENT
4 36333 36835 1.381664052
8 70179 72496 3.301557446
16 169303 175743 3.803831001
32 328837 341093 3.727074508
64 363352 399847 10.04397939
72 372011 413437 11.13569222
128 443979 578355 30.26629638
180 321420 552373 71.85396055
196 276780 558896 101.927885
256 234563 568951 142.5578629

2) Results for read-write workload:
=========================
pgbench -i -s 300 postgres
pgbench -M prepared -c $thread -j $thread -T $time_for_reading  postgres

where, time_for_reading = 30mins

non default param:
shared_buffers=8GB
max_connections=300

CLIENT COUNT TPS (HEAD) TPS (PATCH) % IMPROVEMENT
4 2683 2690 0.2609019754
8 5321 5332 0.2067280586
16 10348 10387 0.3768844221
32 19446 19754 1.58387329
64 28178 28198 0.0709773582
72 28296 28639 1.212185468
128 28577 28600 0.0804843056
180 26665 27525 3.225201575
196 27628 28511 3.19603301
256 28467 28529 0.2177960445

HEAD is basically referring to the following git commit in master branch,

commit 5dbdb2f799232cb1b6df7d7a85d59ade3234d30c
Author: Robert Haas <rhaas(at)postgresql(dot)org>
Date:   Fri Feb 24 12:21:46 2017 +0530

    Make tablesample work with partitioned tables.

    This was an oversight in the original partitioning commit.

    Amit Langote, reviewed by David Fetter

--
With Regards,
Ashutosh Sharma
EnterpriseDB:http://www.enterprisedb.com

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

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

参考

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

https://www.postgresql.org/message-id/flat/CAPpHfdtJY4zOEDsjad6J5AyZMqZcv6gSY9AkKpA7qN3jyQ2+1Q@mail.gmail.com#CAPpHfdtJY4zOEDsjad6J5AyZMqZcv6gSY9AkKpA7qN3jyQ2+1Q@mail.gmail.com

时间: 2024-08-03 07:16:37

PostgreSQL 10.0 preview 性能增强 - pg_xact align(cacheline对齐)的相关文章

震精 - PostgreSQL 10.0 preview 性能增强 - WARM提升一倍性能

标签 PostgreSQL , 10.0 , WARM , 写放大 , 索引写放大 背景 目前,PostgreSQL的MVCC是多版本来实现的,当更新数据时,产生新的版本.(社区正在着手增加基于回滚段的存储引擎) 由于索引存储的是KEY+CTID(行号),当tuple的新版本与旧版本不在同一个数据块(BLOCK)的时候,索引也要随之变化,当新版本在同一个块里面时,则发生HOT UPDATE,索引的值不需要更新,但是因为产生了一条新的记录,所以也需要插入一条索引item,垃圾回收时,将其回收,因此

PostgreSQL 10.0 preview 性能增强 - 推出JIT开发框架(朝着HTAP迈进)

标签 PostgreSQL , 10.0 , HTAP , 动态编译 , JIT , LLVM , 表达式 , 函数跳转 背景 数据库发展了几十年,出现了很多产品,有面向OLTP(在线事务处理)的,有面向OLAP(在线分析)的. 虽然两个场景各有需求特色,但是企业需要为其需求买单,因为目前很少有产品可以同时满足在线处理和在线分析的需求. 比如一家企业,通常都有业务的波峰波谷,比如游戏业务,通常波谷可能是在凌晨,因为大多数人都睡了.而波峰可能出现在每天的工作闲时.游戏运营时段.节假日等. 为了分析

PostgreSQL 10.0 preview 性能增强 - hash index metapage cache、高并发增强

标签 PostgreSQL , 10.0 , hash index 背景 hash index是PostgreSQL中一个非常老的索引访问方法,也是非常经典的索引. hash index中存储的是索引字段的hash value,而不是原始值,btree索引中存储的是原始值. 因此,当字段非常大时,btree索引可能无法使用. 例如 postgres=# create table test_hash_btree(c1 text); CREATE TABLE postgres=# insert in

PostgreSQL 10.0 preview 性能增强 - 分区表性能增强(plan阶段加速)

标签 PostgreSQL , 10.0 , 分区表 , 子表 , 元信息搜索性能增强 背景 PostgreSQL 10.0 增强了分区表的子表搜索性能,对于涉及分区表包含子表特别多的QUERY,可以提升性能. 性能分析 get_tabstat_entry, find_all_inheritors成为主要瓶颈. Hello. I decided to figure out whether current implementation of declarative partitioning has

PostgreSQL 10.0 preview 性能增强 - mergesort(Gather merge)

标签 PostgreSQL , 10.0 , merge sort , gather merge 背景 在数据库中,经常会有多个节点append,然后sort的情况. 例如一张表有10个分区,查询所有分区,并按某列排序输出,常规的做法是所有的记录append,然后sort. PostgreSQL 10.0 将支持append node的并行计算,也就是说所有的分区表可以并行的sort,然后返回,此时就可以使用merge sort来提高排序的速度. 另外,像单表的并行计算,如果需要排序输出的话,每

PostgreSQL 10.0 preview 性能增强 - OLAP提速框架, Faster Expression Evaluation Framework(含JIT)

标签 PostgreSQL , 10.0 , llvm , jit , Faster Expression Evaluation Framework 背景 PostgreSQL 10.0有可能会融合JIT,向量计算等技术,提供一个通用的,便于高效协作,提升OLAP性能的一个开发框架. 虽然目前社区有朋友已经提供了LLVM和向量计算的插件,很显然社区是想在内核中直接整合这些计算的.加油PostgreSQL <分析加速引擎黑科技 - LLVM.列存.多核并行.算子复用 大联姻 - 一起来开启Post

PostgreSQL 10.0 preview 性能增强 - libpq支持pipeline batch模式减少网络交互提升性能

标签 PostgreSQL , 10.0 , libpq , pipeline , batch 背景 PostgreSQL 10.0 libpq支持pipeline batch两种模式,batch模式意味着客户端可以将多个QUERY塞入pipeline,作为一个batch提交给server段,从而减少客户端和服务端的网络交互次数. 在网络环境不太好的环境中,特别是云环境,大幅提升性能. + <application>libpq</application> supports queu

PostgreSQL 10.0 preview 性能增强 - CLOG group commit

标签 PostgreSQL , 10.0 , CLOG , group commit 背景 clog是PostgreSQL的事务提交状态日志,每个事务对应2个BIT,当事务频繁(小事务)结束时,可能出现CLOGControlLock 冲突的问题. 虽然增加clog buffer可以缓解,PostgreSQL 10.0 采样clog group commit进一步降低这个冲突. 提升高并发下的TPS能力. I think the main focus for test in this area w

PostgreSQL 10.0 preview 性能增强 - 间接索引(secondary index)

标签 PostgreSQL , 10.0 , 间接索引 , 第二索引 背景 我们知道,PostgreSQL的MVCC是多版本来实现的,当更新数据时,产生新的版本. 那么如果新版本不在同一个数据块的时候,索引也要随之变化,当新版本在同一个堆表的块里面时,则发生HOT UPDATE,不需要变更没有发生值改变的索引. 但是HOT总不能覆盖100%的更新,所以还是有索引更新的可能存在. 为了解决这个问题,PostgreSQL 10.0引入了第二索引(间接索引)的概念,即在PK或者UK之上,构建其他索引.