Postgres 17beta1 vs sysbench on a large server

This has results from the sysbench benchmark for many versions of Postgres on a large server with a cached and high-concurrency workload. Results from a small server are here. This work was done by Small Datum LLC.

tl;dr

• There are no regressions and many improvements. This is an impressive release.
• Postgres 17beta1 does better for writes relative to 10.23 here with high concurrency than it does on the small server with less concurrency. This commit might explain the improvements.
• The hot-points query became ~2X faster in 17beta1 both on the large and small server

Builds and configuration

I tested Postgres versions 10.23, 11.22, 12.19, 13.15, 14.12, 15.7, 16.3 and 17beta1. Everything was compiled from source. The config files are here and I used the conf.diff.cx9a2_c32r128 variants.

Benchmarks

I used sysbench and my usage is explained here. There are 42 microbenchmarks and most test only 1 type of SQL statement.

Tests were run on a Dell 7865 Tower with 32 cores (1 socket, SMT disabled, AMD Ryzen Threadripper Pro 5975WX), 128G RAM, 2 m.2 SSD (2 TB each, RAID SW 0, XFS) and Ubuntu 22.04. The server is described here as v7.

The benchmark is run with 24 threads (concurrent connections) sharing 8 tables. There were 10M rows per table, 80M total. The command line was:

bash r.sh 8 10000000 300 600 md0 1 1 24

In all cases

• each microbenchmark runs for 300 seconds if read-only and 600 seconds otherwise
• prepared statements were enabled

Results

For the results below I split the 42 microbenchmarks into 5 groups -- 2 for point queries, 2 for range queries, 1 for writes. For the range query microbenchmarks, part 1 has queries that don't do aggregation while part 2 has queries that do aggregation. The spreadsheet with all data and charts is here. For each group I present a chart and a table with summary statistics.

All of the charts have relative throughput on the y-axis where that is (QPS for $me) / (QPS for $base), $me is some DBMS version (for example Postgres 16.3) and $base is Postgres 10.23. The y-axis doesn't start at 0 to improve readability. When the relative throughput is > 1 then that version is faster than the base case.

The legend under the x-axis truncates the names I use for the microbenchmarks and I don't know how to fix that other than sharing links (see above) to the Google Sheets I used.

Summary statistics

This section presents summary statistics of the throughput from Postgres 17beta1 relative to 10.23 for each microbenchmark group. A value greater than one means that 17beta1 gets more throughput than 10.23 which is good news. And there is much good news in the results below. The most extreme good news is the result from the hot-points microbenchmark where 17beta1 gets ~2X more QPS than previous versions. The results here are similar to the results from the small server with one exception. The improvement for writes (median and average) with Postgres 17beta1 is much larger here than on the small server.

	min	max	avg	median	stdev
point-1	1.00	2.05	1.13	1.05	0.31
point-2	1.00	1.05	1.03	1.03	0.02
range-1	1.02	1.14	1.07	1.07	0.03
range-2	1.03	1.07	1.04	1.04	0.02
writes	1.06	1.67	1.31	1.34	0.19

Graphs

There is one graph per microbenchmark group. The y-axis doesn't begin at zero to improve readability.

Graphs for point queries, part 1. The line for hot points (the left-most group) is truncated for 17beta1 because the value is ~2 and I want to focus on readability for results close to 1.

Full table scan became faster starting in Postgres 14 and the improvement remains.

Several of the microbenchmarks became much faster in 17beta1. Hopefully we can eventually assign credit to some of the changes that explain the improvements.

Why are writes faster in 17beta1?

I have a file that includes results from vmstat and iostat per microbenchmark and it includes both absolute and normalized values where normalized means it is metric / QPS which lets me see how much hardware is used per operation. The file is here and the legend for it is:

• cpu/o - vmstat us+sy / QPS, CPU per operation
• cs/o - vmstat cs / QPS, context switches per operation
• r/o - iostat r/s / QPS, storage reads per operation
• rKB/o - iostat read KB / QPS, storage KB read per operation
• wKB/o - iostat write KB / QPS, storage KB written per operation
• o/s - operations/s (throughput, QPS, etc)
• dbms - specifies the database version and config file

There are large speedups in Postgres 17beta1 for update-index and update-nonindex. From the metrics for update-index the context switch rate is half that compared to the rate in 16.3 and the CPU overhead (cpu/o) also dropped. And the changes in metrics for update-nonindex are similar. Something was done to reduce mutex contention in 17beta1 which is good news.

Postgres 17beta1 vs sysbench on a small server

This has results from the sysbench benchmark for many versions of Postgres on a small server with a cached and low-concurrency workload. This work was done by Small Datum LLC.

My standard disclaimer is that sysbench with low-concurrency is great for spotting CPU regressions. However, a result with higher concurrency from a larger server is also needed to understand things. Results from IO-bound workloads and less synthetic workloads are also needed. But low-concurrency, cached sysbench is a great place to start.

tl;dr

• Postgres 17beta1 has no regressions and several improvements.
• Postgres 17beta1 looks great as the median throughput is between 1% and 17% better than Postgres 10.23, excluding the hot-points microbenchmark which is ~2X faster
• One of the microbenchmarks (hot-points) gets ~2X more QPS than previous Postgres releases. The result is so good that I don't trust it yet but I wonder if this is from a change by Peter Geoghegan. From vmstat, 17beta1 cuts the CPU time in half for that query. The 17beta1 release notes state there are changes to improve queries with a large in-list so I believe the 2X speedup here is not a bug 
• There are big improvements in 17beta1 for several of the microbenchmarks that do writes

Other interesting changes:

• This patch might explain some improvements for range queries

Builds and configuration

I tested Postgres versions 10.23, 11.22, 12.19, 13.15, 14.12, 15.7, 16.3 and 17beta1. Everything was compiled from source. The config files are here.

Benchmarks

I used sysbench and my usage is explained here. There are 42 microbenchmarks and most test only 1 type of SQL statement.

Tests were run on my newest small server, an ASUS PN53 with 8 cores, 32G of RAM, an NVMe SSD with XFS and Ubuntu 22.04. The server is described here.

The benchmark is run 3 setups.

• 1u.1t - 1 connection, 1 table with 50M rows
• 4u.1t - 4 connections, 1 table with 50M rows
• 4u.4t - 4 connections, 4 tables with 48M rows (12M per table)

In all cases

• each microbenchmark runs for 300 seconds if read-only and 600 seconds otherwise
• prepared statements were enabled

The command lines for my helper scripts were:

bash r.sh 1 50000000 300 600 nvme1n1 1 1 1

bash r.sh 1 50000000 300 600 nvme1n1 1 1 4

bash r.sh 4 12000000 300 600 nvme1n1 1 1 4

Results

For the results below I split the 42 microbenchmarks into 5 groups -- 2 for point queries, 2 for range queries, 1 for writes. For the range query microbenchmarks, part 1 has queries that don't do aggregation while part 2 has queries that do aggregation. The spreadsheet with all data and charts is here. For each group I present a chart and a table with summary statistics for the three setups: 1u.1t, 4u.1t and 4u.4t.

All of the charts have relative throughput on the y-axis where that is (QPS for $me) / (QPS for $base), $me is some DBMS version (for example Postgres 16.3) and $base is Postgres 10.23. The y-axis doesn't start at 0 to improve readability. When the relative throughput is > 1 then that version is faster than the base case.

The legend under the x-axis truncates the names I use for the microbenchmarks and I don't know how to fix that other than sharing links (see above) to the Google Sheets I used.

Summary statistics

This section presents summary statistics of the throughput from Postgres 17beta1 relative to 10.23 for each microbenchmark group. A value greater than one means that 17beta1 gets more throughput than 10.23 which is good news. And there is much good news in the results below. The most extreme good news is the result from the hot-points microbenchmark where 17beta1 gets ~2X more QPS than previous versions. But that result should be explained before I trust it. 

• sysbench command-line flags used by hot-points are here
• Lua script for hot-points that includes the SQL (large in-list) is here

Stats for 1u.1t

	min	max	avg	median	stdev
point-1	0.97	2.15	1.11	1.00	0.34
point-2	0.98	1.04	1.01	1.01	0.02
range-1	1.04	1.11	1.06	1.06	0.03
range-2	1.03	1.05	1.04	1.04	0.01
writes	1.04	1.22	1.12	1.11	0.06

Stats for 4u.1t

	min	max	avg	median	stdev
point-1	1.00	2.26	1.14	1.03	0.37
point-2	0.98	1.04	1.02	1.02	0.02
range-1	1.02	1.12	1.06	1.06	0.03
range-2	1.03	1.09	1.05	1.04	0.02
writes	1.03	1.56	1.19	1.16	0.15

Stats for 4u.4t

	min	max	avg	median	stdev
point-1	1.02	1.94	1.12	1.04	0.27
point-2	1.02	1.04	1.03	1.03	0.01
range-1	1.03	1.13	1.06	1.05	0.04
range-2	1.02	1.08	1.04	1.04	0.02
writes	1.05	1.40	1.18	1.17	0.11

Graphs

There are three graphs per microbenchmark group - one for each of 1u.1t, 4u.1t and 4u.4t. The y-axis doesn't begin at zero to improve readability.

Graphs for point queries, part 1. Results are similar across 1u.1t, 4u.1t and 4u.4t. The line for hot points (the left-most group) is truncated for 17beta1 because the value is ~2 and I want to focus on readability for results close to 1.

Graphs for point queries, part 2.

Graphs for range queries, part 1.

Graphs for range queries, part 2.

Graphs for writes. The y-axis goes to 1.6 because there are a few large improvements in 17beta1. While that makes some of the lines that end near 1.0 harder to read, this is a good problem to have.

Does disabling full_page_writes reduce variance for Postgres with a cached Insert Benchmark

This is a follow up to my previous benchmark report. While Postgres does a great job at avoiding performance regressions (performance doesn't get worse over time) it also hasn't gotten better over time with respect to variance on some of the steps of the Insert Benchmark.

Two of the benchmark steps (l.i0, l.i1 -- see here) do deletes in one connection, inserts in the other and the benchmark client does them at the same rate. If deletes are slow then inserts will be slow, and vice versa. The per-second rates for inserts and deletes have too much variance (see here). From the response time histograms it is obvious that the problem is that deletes are slower.

Updates:

1. based on advice from experts I repeated tests after adding vacuum_index_cleanup=ON to the create table SQL and with that throughput dropped by ~7% while CPU increased by ~20%
2. A patch to enforce VISITED_PAGES_LIMIT during get_actual_variable_range makes a huge difference

I am not a fan of vacuum

The issue isn't new to me. The root cause is the overhead from get_actual_variable_range trying to figure out the min value of the PK column by reading from the index, and that takes too much time when it must scan and skip many not-visible index entries that will eventually be removed when vacuum runs again. See my posts on this topic. If your writes are clustered in a key range then any query that encounters such a range will be slower than expected because there can be a long time between committing the writes and vacuum cleaning them up leaving much work for queries to scan and skip.

Results

So I repeated the Insert Benchmark for Postgres 16.3 with a cached workload and a small server which is the same setup as reported here. This time I only ran it for two configurations:

• pg163_def.cx9a2_c8r32 - Postgres 16.3 with the cx9a2_c8r32 config as previously used
• pg163_def.cx9a2nofpw_c8r32 - Postgres 16.3 with the cx9a2nofpw_c8r32 config that starts with the cx9a_c8r32 config and then adds full_page_writes=off.

The results are here

• Throughput is similar for all benchmark steps
• KB written to storage per insert (wkbpi) are reduced with full_page_writes=off for the l.i1 and l.i2 benchmark steps that are write heavy. This is expected.
• Using full_page_writes=off doesn't fix the throughput variance problem and from the response time histograms the root cause remains the same (delete statements).
• LWN reported on this recently and I look forward to widespread support for atomic writes across SSD vendors with Linux. Even more so when this doesn't require a proprietary file system or vendor API. With such support everyone can safely use full_page_writes=off and turn off the InnoDB doublewrite buffer.
• If you scroll down on the IPS charts here you reach more charts for DPS (deletes/s) and max delete response time, both over 1 second intervals. While the max insert response time chart doesn't show variance, the max delete response time chart shows much variance. From the chart there are ~16 spikes at regular intervals over 3237 seconds or one per ~200 seconds.

From logs that I have not shared for the full_page_writes=off result:

• the l.i0 step started at 11:07 and finished at 11:13
• the l.x step finished at 11:15
• the l.i1 step finished at 12:09
• one checkpoint started and completed when it was running, then a second checkpoint started but did not finish (see below)
• many vacuums were done during this step and the interval between the spikes on the delete graphs aligns with the vacuum jobs listed below
• the l.i2 step finished at 14:07
• vacuum was one for the test table followed by checkpoint, this finished at 14:09
• the read-write test steps were done in sequence: qr100, qp100, ..., qr1000, qp1000 and qp1000 finished at 20:10, each runs for 1 hour

The full output for logfile is here for the test with full_page_writes=ON and full_page_writes=OFF.

The following is from the test with full_page_writes=OFF.

Output from grep checkpoint logfile is here and grep "checkpoint starting" logfile output is below:

2024-06-02 11:07:38.612 UTC [1340363] LOG:  checkpoint starting: immediate force wait

2024-06-02 11:37:39.041 UTC [1340363] LOG:  checkpoint starting: time

2024-06-02 12:07:39.938 UTC [1340363] LOG:  checkpoint starting: time

2024-06-02 12:37:39.817 UTC [1340363] LOG:  checkpoint starting: time

2024-06-02 13:07:39.765 UTC [1340363] LOG:  checkpoint starting: time

2024-06-02 13:37:39.609 UTC [1340363] LOG:  checkpoint starting: time

2024-06-02 14:07:39.717 UTC [1340363] LOG:  checkpoint starting: time

2024-06-02 14:08:04.767 UTC [1340363] LOG:  checkpoint starting: immediate force wait

2024-06-02 14:38:05.017 UTC [1340363] LOG:  checkpoint starting: time

2024-06-02 15:08:05.261 UTC [1340363] LOG:  checkpoint starting: time

2024-06-02 15:38:05.265 UTC [1340363] LOG:  checkpoint starting: time

2024-06-02 16:08:05.181 UTC [1340363] LOG:  checkpoint starting: time

2024-06-02 16:38:05.211 UTC [1340363] LOG:  checkpoint starting: time

2024-06-02 17:08:05.436 UTC [1340363] LOG:  checkpoint starting: time

2024-06-02 17:38:05.545 UTC [1340363] LOG:  checkpoint starting: time

2024-06-02 18:08:05.581 UTC [1340363] LOG:  checkpoint starting: time

2024-06-02 18:38:05.401 UTC [1340363] LOG:  checkpoint starting: time

2024-06-02 19:08:05.801 UTC [1340363] LOG:  checkpoint starting: time

2024-06-02 19:38:05.757 UTC [1340363] LOG:  checkpoint starting: time

2024-06-02 20:08:05.629 UTC [1340363] LOG:  checkpoint starting: time

The output from grep vacuum logfile is below and the spikes above for the per-second delete rates appear to align with the vacuum frequency show below. The first vacuums for the pi1 table are fast and more frquent because index scans: 0 is shown for them -- so they do less work. Eventually vacuums that have index scans: 1 are done every ~4 minutes.

Note that I recently began using index_cleanup ON as an option to the manual vacuums done after the l.i2 step finishes, otherwise indexes are cleaned given the current heuristics. Unfortunately, I don't yet know whether there is a way (or whether I need to do it) for the automatic vacuums that represent the majority of the vacuum jobs listed below.

2024-06-02 11:07:39.879 UTC [1340408] LOG:  automatic aggressive vacuum of table "template1.pg_catalog.pg_attribute": index scans: 0

2024-06-02 11:07:39.888 UTC [1340408] LOG:  automatic aggressive vacuum of table "template1.pg_catalog.pg_class": index scans: 0

2024-06-02 11:07:39.892 UTC [1340408] LOG:  automatic aggressive vacuum of table "template1.pg_catalog.pg_description": index scans: 0

2024-06-02 11:07:39.896 UTC [1340408] LOG:  automatic aggressive vacuum of table "template1.pg_catalog.pg_depend": index scans: 1

2024-06-02 11:07:46.574 UTC [1340428] LOG:  automatic vacuum of table "ib.public.pi1": index scans: 0

2024-06-02 11:07:51.646 UTC [1340430] LOG:  automatic aggressive vacuum of table "template1.pg_catalog.pg_statistic": index scans: 1

2024-06-02 11:07:56.670 UTC [1340433] LOG:  automatic vacuum of table "ib.public.pi1": index scans: 0

2024-06-02 11:08:06.671 UTC [1340437] LOG:  automatic vacuum of table "ib.public.pi1": index scans: 0

2024-06-02 11:08:16.673 UTC [1340447] LOG:  automatic vacuum of table "ib.public.pi1": index scans: 0

2024-06-02 11:08:26.674 UTC [1340451] LOG:  automatic vacuum of table "ib.public.pi1": index scans: 0

2024-06-02 11:08:36.675 UTC [1340464] LOG:  automatic vacuum of table "ib.public.pi1": index scans: 0

2024-06-02 11:08:46.678 UTC [1340474] LOG:  automatic vacuum of table "ib.public.pi1": index scans: 0

2024-06-02 11:08:56.679 UTC [1340478] LOG:  automatic vacuum of table "ib.public.pi1": index scans: 0

2024-06-02 11:09:06.680 UTC [1340482] LOG:  automatic vacuum of table "ib.public.pi1": index scans: 0

2024-06-02 11:09:16.681 UTC [1340492] LOG:  automatic vacuum of table "ib.public.pi1": index scans: 0

2024-06-02 11:09:26.681 UTC [1340496] LOG:  automatic vacuum of table "ib.public.pi1": index scans: 0

2024-06-02 11:09:36.782 UTC [1340509] LOG:  automatic vacuum of table "ib.public.pi1": index scans: 0

2024-06-02 11:09:46.882 UTC [1340519] LOG:  automatic vacuum of table "ib.public.pi1": index scans: 0

2024-06-02 11:09:56.982 UTC [1340523] LOG:  automatic vacuum of table "ib.public.pi1": index scans: 0

2024-06-02 11:10:06.983 UTC [1340528] LOG:  automatic vacuum of table "ib.public.pi1": index scans: 0

2024-06-02 11:10:16.985 UTC [1340538] LOG:  automatic vacuum of table "ib.public.pi1": index scans: 0

2024-06-02 11:10:26.986 UTC [1340542] LOG:  automatic vacuum of table "ib.public.pi1": index scans: 0

2024-06-02 11:10:37.088 UTC [1340555] LOG:  automatic vacuum of table "ib.public.pi1": index scans: 0

2024-06-02 11:10:47.089 UTC [1340565] LOG:  automatic vacuum of table "ib.public.pi1": index scans: 0

2024-06-02 11:10:57.091 UTC [1340569] LOG:  automatic vacuum of table "ib.public.pi1": index scans: 0

2024-06-02 11:11:07.092 UTC [1340573] LOG:  automatic vacuum of table "ib.public.pi1": index scans: 0

2024-06-02 11:11:27.213 UTC [1340588] LOG:  automatic vacuum of table "ib.public.pi1": index scans: 0

2024-06-02 11:11:47.316 UTC [1340611] LOG:  automatic vacuum of table "ib.public.pi1": index scans: 0

2024-06-02 11:12:07.319 UTC [1340619] LOG:  automatic vacuum of table "ib.public.pi1": index scans: 0

2024-06-02 11:12:30.655 UTC [1340634] LOG:  automatic vacuum of table "ib.public.pi1": index scans: 0

2024-06-02 11:12:50.621 UTC [1340657] LOG:  automatic vacuum of table "ib.public.pi1": index scans: 0

2024-06-02 11:13:10.625 UTC [1340671] LOG:  automatic vacuum of table "ib.public.pi1": index scans: 0

2024-06-02 11:17:00.374 UTC [1341771] LOG:  automatic vacuum of table "ib.public.pi1": index scans: 1

2024-06-02 11:20:37.635 UTC [1341979] LOG:  automatic vacuum of table "ib.public.pi1": index scans: 1

2024-06-02 11:24:08.272 UTC [1342191] LOG:  automatic vacuum of table "ib.public.pi1": index scans: 1

2024-06-02 11:27:32.919 UTC [1342394] LOG:  automatic vacuum of table "ib.public.pi1": index scans: 1

2024-06-02 11:31:36.540 UTC [1342628] LOG:  automatic vacuum of table "ib.public.pi1": index scans: 1

2024-06-02 11:35:01.656 UTC [1342836] LOG:  automatic vacuum of table "ib.public.pi1": index scans: 1

2024-06-02 11:38:42.656 UTC [1343055] LOG:  automatic vacuum of table "ib.public.pi1": index scans: 1

2024-06-02 11:42:38.499 UTC [1343281] LOG:  automatic vacuum of table "ib.public.pi1": index scans: 1

2024-06-02 11:45:52.954 UTC [1343488] LOG:  automatic vacuum of table "ib.public.pi1": index scans: 1

2024-06-02 11:49:16.466 UTC [1343691] LOG:  automatic vacuum of table "ib.public.pi1": index scans: 1

2024-06-02 11:52:49.834 UTC [1343896] LOG:  automatic vacuum of table "ib.public.pi1": index scans: 1

2024-06-02 11:56:09.758 UTC [1344102] LOG:  automatic vacuum of table "ib.public.pi1": index scans: 1

2024-06-02 11:59:40.492 UTC [1344308] LOG:  automatic vacuum of table "ib.public.pi1": index scans: 1

2024-06-02 12:02:56.674 UTC [1344514] LOG:  automatic vacuum of table "ib.public.pi1": index scans: 1

2024-06-02 12:06:14.134 UTC [1344715] LOG:  automatic vacuum of table "ib.public.pi1": index scans: 1

2024-06-02 12:09:27.171 UTC [1344905] LOG:  automatic vacuum of table "ib.public.pi1": index scans: 1

2024-06-02 12:39:11.117 UTC [1347226] LOG:  automatic vacuum of table "ib.public.pi1": index scans: 1

2024-06-02 13:07:49.413 UTC [1349013] LOG:  automatic vacuum of table "ib.public.pi1": index scans: 1

2024-06-02 13:36:56.651 UTC [1350908] LOG:  automatic vacuum of table "ib.public.pi1": index scans: 1

2024-06-02 14:07:32.120 UTC [1352802] LOG:  automatic vacuum of table "ib.public.pi1": index scans: 1

2024-06-02 17:09:33.324 UTC [1586393] LOG:  automatic vacuum of table "ib.public.pi1": index scans: 1

2024-06-02 18:21:56.439 UTC [1811927] LOG:  automatic vacuum of table "ib.public.pi1": index scans: 1

2024-06-02 19:03:48.109 UTC [1813892] LOG:  automatic vacuum of table "ib.public.pi1": index scans: 1

2024-06-02 19:45:44.782 UTC [1946850] LOG:  automatic vacuum of table "ib.public.pi1": index scans: 1

Update 1: try vacuum_index_cleanup=ON

A new performance report is here after I changed the benchmark client to add WITH ( vacuum_index_cleanup=ON) to the create table SQL. Throughput was reduced by ~7% for many of the benchmark steps with that change. The per-second charts for inserts/s, delete/s, insert response time and delete response time for the l.i1 benchmark step are here and some of the charts look a bit worse with vacuum_index_cleanup=ON.

The DBMS tested are:

• pg163_def.cx9a2_c8r32 - full_page_writes=ON, doesn't use vacuum_index_cleanup
•  logfile is here 
• pg163_def.cx9a2vic_c8r32 - full_page_writes=ON, does use vacuum_index_cleanup
• logfile is here
• pg163_def.cx9a2nofpw_c8r32 - full_page_writes=OFF, doesn't use vacuum_index_cleanup
• logfile is here
• pg163_def.cx9a2nofpwvic_c8r32 - full_page_writes=OFF, does use vacuum_index_cleanup
• logfile is here

From the metrics for the l.i1 benchmark step that does random writes the CPU per insert (cpupq) is at least 1.2X larger with vacuum_index_cleanup=ON. Other metrics changed but that was the largest.

From a simple analysis of logfile, I count the number of automatic vacuum entries with index scans: 1 and index scans: 0.

• pg163_def.cx9a2_c8r32 - 27 for scans: 0 vs 24 for scans: 1
• pg163_def.cx9a2vic_c8r32 - 28 for scans: 0 vs 24 for scans: 1
• pg163_def.cx9a2nofpw_c8r32 - 27 for scans: 0 vs 24 for scans: 1
• pg163_def.cx9a2nofpwvic_c8r32 - 28 for scans: 0 vs 24 for scans: 1

Update 2: the patch

There is a patch to enforce VISITED_PAGES_LIMIT during get_actual_variable_range calls. The patch as written keeps it at 100 and I tried it with two variations -- as-is (=100) and then I reduced it to 10. Then I repeated the Insert Benchmark on the small server with a cached database for 3 binaries:

• pg17beta1_def.cx9a2_c8r32
• Postgres 17beta1 with the cx9a2_c8r32 config
• pg17beta1_def_hack10.cx9a2_c8r32
• Postgres 17beta1 with the cx9a2_c8r32 config and a patch with VISITED_PAGES_LIMIT=10 enforced during get_actual_variable_range
• pg17beta1_def_hack100.cx9a2_c8r32
• Postgres 17beta1 with the cx9a2_c8r32 config and a patch with VISITED_PAGES_LIMIT=100 enforced during get_actual_variable_range

The patch improves throughput on l.i1 by ~5X and on l.i2 by ~20X because it reduces the CPU overhead of the optimizer during DELETE statements and DELETE throughput was the bottleneck.

• the performance summary is here which shows the ~5X and ~20X improvements
• the charts for per second throughput and response time are here and the improvement is obvious. The insert and delete rates have much variance without the patch while they look much better with the patch (here and here)
• response time histograms are here and there is a huge improvement for DELETE statements

The Insert Benchmark, Postgres 17beta1, a small server and cached database

This post has results for the Insert Benchmark on a small server with a cached workload. The goal is to compare new Postgres releases with older ones to determine whether they get better or worse over time. The results here are from the newest small servers in my test cluster -- an ASUS PN53.

This work was done by Small Datum LLC.

The workload here has low concurrency (1 or 4 clients) and the database is cached. The results might be different when the workload is IO-bound or has more concurrency. Results were recently shared from tests run on an older small server. 

tl;dr

• There are no regressions from Postgres 16.3 to 17beta1 for this benchmark
• All Postgres versions have too much variance on the insert rate for the l.i1 and l.i2 benchmark steps. While tuning fixes that is a too frequent response, I spent much time trying to fix this via tuning last year without success. This has not been a problem for modern MySQL and one example is here (equivalent Postgres graphs are here). The issue is explained below.
• The builtin provider might have improved performance on two of the benchmark steps (l.i1, l.i2) when comparing Postgres 17beta1 with and without it. But I need to repeat the benchmark to confirm that the result isn't just noise.

Build + Configuration

This post has results from Postgres versions 10.23, 11.22, 12.19, 13.15, 14.12, 15.7, 16.3 and 17beta1. All were compiled from source. I used configurations that are as similar as possible but I won't have access to the test machines for a few days. The config for 16.3 is here.

For Postgres 17beta1 I have results for two different configs (cx9a2_c8r32, cx9a2lc_c8r32). But they really are the same config. The difference is in the flags to initdb:

• cx9a2_c8r32 - --data-checksums
• cx9a2lc_c8r32 - --data-checksums --locale-provider=builtin --builtin-local=C.UTF-8

This was done to see if the changes in 17beta1 for the builtin local provider impact performance. The output from running initdb for Postgres 17beta1 is here.

The Benchmark

The benchmark is run with 1 client, a cached workload and 1 table. It is explained here.

The test server was named v8 here and is an ASUS PN53. It has 8 cores, 32G RAM, Ubuntu 22.04 and XFS using 1 m.2 device.

The benchmark steps are:

• l.i0
• insert 50 million rows in PK order. The table has a PK index but no secondary indexes. There is one connection per client.
• l.x
• create 3 secondary indexes per table. There is one connection per client.
• l.i1
• use 2 connections/client. One inserts 40M rows and the other does deletes at the same rate as the inserts. Each transaction modifies 50 rows (big transactions). This step is run for a fixed number of inserts, so the run time varies depending on the insert rate.
• l.i2
• like l.i1 but each transaction modifies 5 rows (small transactions) and 10M rows are inserted and deleted.
• Wait for X seconds after the step finishes to reduce variance during the read-write benchmark steps that follow. The value of X is a function of the table size.
• qr100
• use 3 connections/client. One does range queries and performance is reported for this. The second does does 100 inserts/s and the third does 100 deletes/s. The second and third are less busy than the first. The range queries use covering secondary indexes. This step is run for 1800 seconds. If the target insert rate is not sustained then that is considered to be an SLA failure. If the target insert rate is sustained then the step does the same number of inserts for all systems tested.
• qp100
• like qr100 except uses point queries on the PK index
• qr500
• like qr100 but the insert and delete rates are increased from 100/s to 500/s
• qp500
• like qp100 but the insert and delete rates are increased from 100/s to 500/s
• qr1000
• like qr100 but the insert and delete rates are increased from 100/s to 1000/s
• qp1000
• like qp100 but the insert and delete rates are increased from 100/s to 1000/s

Results

The performance report is here.

The summary in each performance report has 3 tables. The first shows absolute throughput by DBMS tested X benchmark step. The second has throughput relative to the version from the first row of the table. The third shows the background insert rate for benchmark steps with background inserts and all systems sustained the target rates. The second table makes it easy to see how performance changes over time. The third table makes it easy to see which DBMS+configs failed to meet the SLA.

Below I use relative QPS to explain how performance changes. It is: (QPS for $me / QPS for $base) where $me is my version and $base is the version of the base case. When relative QPS is > 1.0 then performance improved over time. When it is < 1.0 then there are regressions. The Q in relative QPS measures: 

• insert/s for l.i0, l.i1, l.i2
• indexed rows/s for l.x
• range queries/s for qr100, qr500, qr1000
• point queries/s for qp100, qp500, qp1000

Below I use colors to highlight the relative QPS values with red for <= 0.95, green for >= 1.05 and grey for values between 0.95 and 1.05.

Results: Postgres

The base case is Postgres 10.23 with the cx9a2_c8r32 config (pg1023_def.cx9a2_c8r32). It is compared with:

• Postgres 16.3 with the cx9a2_c8r32 config (pg163_def.cx9a2_c8r32)
• Postgres 17beta1 with the cx9a2_c8r32 config (pg17beta1_def.cx9a2_c8r32)
• Postgres 17beta1 with the cx9a2lc_c8r32 config (pg17beta1_def.cx9a2lc_c8r32) that uses the builtin locale provider

tl;dr

• Postgres 16.3 and 17beta1 have similar performance
• It isn't clear that the builtin provider helps this benchmark
• The results for l.i1 and l.i2 should be revisited to explain why 17beta1 without the builtin locale provider didn't do better

From the summary the relative throughput per benchmark step is:

• l.i0
• relative QPS is 1.14 in PG 16.3
• relative QPS is 1.18 in PG 17beta1 without the builtin locale
• relative QPS is 1.18 in PG 17beta1 with the builtin locale
• l.x - I ignore this for now
• l.i1, l.i2
• relative QPS is 2.23, 2.27 in PG 16.3
• relative QPS is 1.99, 2.00 in PG 17beta1 without the builtin locale
• relative QPS is 2.29, 2.22 in PG 17beta1 with the builtin locale
• qr100, qr500, qr1000
• relative QPS is 1.03, 1.08, 1.08 in PG 16.3
• relative QPS is 1.04, 1.07, 1.08 in PG 17beta1 without the builtin locale
• relative QPS is 1.05, 1.07, 1.07 in PG 17beta1 with the builtin locale
• qp100, qp500, qp1000
• relative QPS is 0.98, 0.98, 0.97 in PG 16.3
• relative QPS is 0.97, 0.98, 0.97 in PG 17beta1 without the builtin locale
• relative QPS is 0.96, 0.97, 0.96 in PG 17beta1 with the builtin locale

Metrics

Metrics for each of the benchmark steps starts here. By metrics I mean mostly counters from iostat and vmstat normalized by the insert or query rates. These help to explain differences in performance and spot where something is using more or less HW per operation. Here I focus on the metrics for the l.i1 and l.i2 benchmark steps because that is where there is a difference for Postgres 17beta1 with and without the builtin locale provider.

The thing to explain is that the insert (and delete) rates sustained by Postgres 17beta1 with the builtin locale provider are better than without it. Note that the benchmark client is setup so that the insert and delete rates are coupled -- they are programmed to run at the same rate. The difference in the results here is about 15%. The most interesting difference in the metrics for l.i1 is in the CPU/operation (cpupq) column where it about 8% larger without the builtin locale provider (127 vs 117).

The other interesting result is that the number of context switches per operation (cspq) is about 15% smaller in Postgres 17beta1 vs 16.3. This is a good change, but I want to see more results before I am certain about it.

Variance

All Postgres versions have too much variance on the insert rate for the l.i1 and l.i2 benchmark steps -- see the graphs for insert/s vs time here (IPS == inserts/s, DPS == deletes/s). While tuning fixes that is a too frequent response, I spent much time trying to fix this via tuning last year without success. This has not been a problem for modern MySQL and one example is here (equivalent Postgres graphs are here).

The response time histograms for l.i1 makes this easier to understand. The histograms are great for inserts but lousy for deletes. The problems is explained in this Twitter thread and blog post. The issue is that the Postgres optimizer probes an index to figure out the min value for a column in some cases, and while this part of the benchmark isn't written in the best way, I still prefer that Postgres do better here and get_actual_variable_range is the culprit.

I updated the Insert Benchmark last year to add deletes at the same rate as inserts for the l.i1 and l.i2 benchmark steps to avoid growing the database. And Postgres was much less happy with that change when compared to MySQL. Note that MySQL with InnoDB often probes indexes to determine predicate selectivity. The real issue here is the number of dead index entries that must be skipped to find the first live entry while figuring out the min value.