PostgreSQL TPROC-C基准测试：PostgreSQL 12与PostgreSQL 13性能对比

postgresql13.0刚刚发布，并在各个方面进行了许多性能改进。为了了解这些变化带来了的差异，我使用HammerDB对不同数量的虚拟用户运行了许多基准测试，比较了未调整配置和“启动程序”调整配置的PostgreSQL 12.4和13.0，即我们建议用户将其用作自己的部署的起点。

被测服务器（ SUT ）是运行 Red Hat Enterprise Linux 版本 8.2 （ Ootpa ）的 Amazon AWS m5.metal 实例   PostgreSQL 数据目录位于 RAID 10 中配置的八个磁盘上。文件系统为 xfs ，预读设置为 8192 。、

PostgreSQL WAL目录位于其自己的磁盘上。文件系统为 xfs，预读设置为 8192。

这些测试在社区软件包中的 PostgreSQL 12.4和 PostgreSQL 13.0上运行。每个服务器的测试大多未经调整。

所有其他设置保持默认值。

所有其他设置保持默认值。

使用的测试驱动程序是 HammerDB，对数据模型进行了一些修改，以使用适当的 PostgreSQL 数据类型，优化列顺序进行对齐，并删除填充因子设置（有关使用的确切模式，请参见本文结尾处的 “ 数据模型 ” 部分） ）。这些修改符合 TPC-C 规范：

第1.3节—表格布局

对于每个表，可以使用从测试系统获得的任何物理表示形式，以任何顺序实现以下属性列表。

HammerDB 使用的算法未做任何更改。

HammerDB 使用 2000 个仓库填充该数据库。每个表都通过其主键索引进行聚类（历史记录中没有索引）。 ANALYZE 和 VACUUM FREEZE 在所有表上运行。保留此原始数据库的基本备份。

对于每个虚拟用户数，都会从基本备份中还原一个新数据库。然后以5 分钟的加速时间和1 小时的测试时间运行HammerDB 。  请注意，思考和关键时间已禁用，因为此测试的目的是查看最大可能的性能。这不能反映实际的工作量，也不适合运行“ 按本就算” 的TPC-C 基准测试。 注意：对于正确的TPC-C 基准测试，测试必须运行至少两个小时。

下表显示了开箱即用和正确调整的 12.4 和 13.0 的结果。值表示每分钟的交易量。   从该图表中我们可以看到， 12.4 和 13.0 的未调整性能基本相同，其中 13.0 具有优势，并且性能在 50 至 75 个虚拟用户数之间最大化。

如果进行适当的调整，我们每分钟的事务数量最多可以达到8倍，并随着虚拟用户数量的增加而维持下去。

在未调整和调整的13.0之间可以看到相同的结果。

如果将经过适当调整的12.4和13.0进行比较，则可以看到250个虚拟用户数每分钟的事务处理速度提高了近20％，然后慢慢回落到12.4的水平。

测试表明，正确调整PostgreSQL 服务器具有巨大的好处。13.0 版的开箱即用性能比12.4 更好，并且在调整两个服务器时的差异甚至更大。PostgreSQL 13 代表了开源关系数据库的又一次飞跃，因为它随着每个新版本的发布而不断完善 。

CREATE TABLE customer (     c_since timestamp with time zone NOT NULL,     c_id integer NOT NULL,     c_w_id integer NOT NULL,     c_d_id smallint NOT NULL,     c_payment_cnt smallint NOT NULL,     c_delivery_cnt smallint NOT NULL,     c_first character varying(16) NOT NULL,     c_middle character(2) NOT NULL,     c_last character varying(16) NOT NULL,     c_street_1 character varying(20) NOT NULL,     c_street_2 character varying(20) NOT NULL,     c_city character varying(20) NOT NULL,     c_state character(2) NOT NULL,     c_zip character(9) NOT NULL,     c_phone character(16) NOT NULL,     c_credit character(2) NOT NULL,     c_credit_lim numeric(12,2) NOT NULL,     c_discount numeric(4,4) NOT NULL,     c_balance numeric(12,2) NOT NULL,     c_ytd_payment numeric(12,2) NOT NULL,     c_data character varying(500) NOT NULL,     CONSTRAINT customer_i1 PRIMARY KEY (c_w_id, c_d_id, c_id) ); CREATE UNIQUE INDEX customer_i2 ON customer USING btree (c_w_id, c_d_id, c_last, c_first, c_id); CREATE TABLE district (     d_w_id integer NOT NULL,     d_next_o_id integer NOT NULL,     d_id smallint NOT NULL,     d_ytd numeric(12,2) NOT NULL,     d_tax numeric(4,4) NOT NULL,     d_name character varying(10) NOT NULL,     d_street_1 character varying(20) NOT NULL,     d_street_2 character varying(20) NOT NULL,     d_city character varying(20) NOT NULL,     d_state character(2) NOT NULL,     d_zip character(9) NOT NULL,     CONSTRAINT district_i1 PRIMARY KEY (d_w_id, d_id) ); CREATE TABLE history (     h_date timestamp with time zone NOT NULL,     h_c_id integer,     h_c_w_id integer NOT NULL,     h_w_id integer NOT NULL,     h_c_d_id smallint NOT NULL,     h_d_id smallint NOT NULL,     h_amount numeric(6,2) NOT NULL,     h_data character varying(24) NOT NULL ); CREATE TABLE item (     i_id integer NOT NULL,     i_im_id integer NOT NULL,     i_name character varying(24) NOT NULL,     i_price numeric(5,2) NOT NULL,     i_data character varying(50) NOT NULL,     CONSTRAINT item_i1 PRIMARY KEY (i_id) ); CREATE TABLE new_order (     no_w_id integer NOT NULL,     no_o_id integer NOT NULL,     no_d_id smallint NOT NULL,     CONSTRAINT new_order_i1 PRIMARY KEY (no_w_id, no_d_id, no_o_id) ); CREATE TABLE order_line (     ol_delivery_d timestamp with time zone,     ol_o_id integer NOT NULL,     ol_w_id integer NOT NULL,     ol_i_id integer NOT NULL,     ol_supply_w_id integer NOT NULL,     ol_d_id smallint NOT NULL,     ol_number smallint NOT NULL,     ol_quantity smallint NOT NULL,     ol_amount numeric(6,2),     ol_dist_info character(24),     CONSTRAINT order_line_i1 PRIMARY KEY (ol_w_id, ol_d_id, ol_o_id, ol_number) ); CREATE TABLE orders (     o_entry_d timestamp with time zone NOT NULL,     o_id integer NOT NULL,     o_w_id integer NOT NULL,     o_c_id integer NOT NULL,     o_d_id smallint NOT NULL,     o_carrier_id smallint,     o_ol_cnt smallint NOT NULL,     o_all_local smallint NOT NULL,     CONSTRAINT orders_i1 PRIMARY KEY (o_w_id, o_d_id, o_id) ); CREATE UNIQUE INDEX orders_i2 ON orders USING btree (o_w_id, o_d_id, o_c_id, o_id); CREATE TABLE stock (     s_i_id integer NOT NULL,     s_w_id integer NOT NULL,     s_ytd integer NOT NULL,     s_quantity smallint NOT NULL,     s_order_cnt smallint NOT NULL,     s_remote_cnt smallint NOT NULL,     s_dist_01 character(24) NOT NULL,     s_dist_02 character(24) NOT NULL,     s_dist_03 character(24) NOT NULL,     s_dist_04 character(24) NOT NULL,     s_dist_05 character(24) NOT NULL,     s_dist_06 character(24) NOT NULL,     s_dist_07 character(24) NOT NULL,     s_dist_08 character(24) NOT NULL,     s_dist_09 character(24) NOT NULL,     s_dist_10 character(24) NOT NULL,     s_data character varying(50) NOT NULL,     CONSTRAINT stock_i1 PRIMARY KEY (s_w_id, s_i_id) ); CREATE TABLE warehouse (     w_id integer NOT NULL,     w_name character varying(10) NOT NULL,     w_street_1 character varying(20) NOT NULL,     w_street_2 character varying(20) NOT NULL,     w_city character varying(20) NOT NULL,     w_state character(2) NOT NULL,     w_zip character(9) NOT NULL,     w_tax numeric(4,4) NOT NULL,     w_ytd numeric(12,2) NOT NULL,     CONSTRAINT warehouse_i1 PRIMARY KEY (w_id) ); 原文链接：https://www.enterprisedb.com/blog/postgresql-tproc-c-benchmarks-postgresql-12-vs-postgresql-13-performance