Small Datum

This has benchmark results for MySQL and Postgres vs the Insert Benchmark on a large server. My intent is to document how performance changes over time more so than start a Postgres vs MySQL argument. MySQL has accumulated large regressions from 5.6 to 8.0 that are obvious on low-concurrency benchmarks. While they are less obvious on high-concurrency benchmarks, and there have been significant improvements to make MySQL 8 better at high-concurrency, the regressions that hurt low-concurrency results also reduce throughput at high-concurrency. tl;dr For Postgres 17rc1 vs 15.8 Performance is mostly the same For MySQL 8.0.39 vs 5.6.51 Writes are much faster in 8.0.39 Reads throughput is mixed,  8.0.39 is slower than, similar to and faster than 5.6.51 depending on the context For MySQL vs Postgres MySQL is faster on point queries Postgres is faster on writes and range queries Builds, configuration and hardware I compiled from source: Postgres versions 17rc1 from source using  -O2 -fno-omit-

For a few years I have only used sysbench and the Insert Benchmark for work but now I need an HTAP benchmark. There are several to choose from but I will start with HATrick. The source is here . It uses C++ and ODBC. I prefer Java (and JDBC), golang or Python but lets see how this goes. My current OS is Ubuntu 22.04 and I install MySQL in custom locations so I assume that I need to install MySQL's Connector/ODBC from source. That depends on an ODBC driver manager, and for Ubuntu I will try iodbc. I have no experience with ODBC and now I am worried about pointless complexity (I am looking at you Log4J, CORBA and EJB). The benchmark looks interesting and useful but I'd rather not deal with setting up ODBC again, nor with core dumps. So I will move on and try CH-benchmark from benchmark (Java + JDBC). The details So the first step is to install iodbc via: sudo apt install libiodbc2 libiodbc2-dev Then configure MySQL Connector/ODBC. I didn't expect to need ODBC_INCLUDES= becaus

This has benchmark results for MySQL 5.6.51, 5.7.44 and 8.0.39 using sysbench on a large server. I also add a few results comparing Postgres 17rc1 with MySQL 8.0.39. My goal with that is to highlight things that can be made better in MySQL (and in Postgres). One of the responses to my claims that MySQL is getting too many performance regressions over time is that this is true for low-concurrency tests but not for high-concurrency tests. Alas, that claim is more truthy than true and fixing some of these regressions would help make modern MySQL not look so slow when compared to modern Postgres. tl;dr MySQL 8.0 is faster than 5.6 for point queries and writes but slower for range queries PostgresSQL 17rc1 is a lot faster than MySQL 8.0 for point queries and writes. For range queries Postgres was still faster but the difference was usually not as large. Builds, configuration and hardware I compiled  Postgres versions 17rc1 from source using  -O2 -fno-omit-frame-pointer . MySQL versions 5.6.

In this post I have more results on the impact of compile-time options for MySQL, InnoDB and sysbench. I previously wrote about the impact of PGO and LTO on MySQL performance. tl;dr There is no silver bullet to undo the performance regressions You can improve QPS by 10% to 20% with -O3, LTO and disabling most of the perf schema at compile time but I am reluctant to suggest running in production without the perf schema You can improve QPS by 5% to 10% with -O3 and LTO Compiling with -Os is bad for performance Builds I used InnoDB from MySQL 8.0.39. The compiler was gcc 11.4.0. The base case was named my8039_rel_o2nofp.z11a_bee and was compiled with -O2 and frame pointers enabled. The CMake command line is here . All of the CMake files are here  and I tested the following variations where the names are in two parts as in build.config where build names the install directory (and the build) and config names the my.cnf file. While the suffix for config files here is _bee , that is only us

This has benchmark results for Postgres 15.8, 16.4 and 17 (beta3, rc1) using sysbench with large and small servers. A recent result for Postgres 17 beta3 from a large server  is here . The server in this case is an  ax162-s  from Hetzner. This work was done by  Small Datum LLC . tl;dr 17rc1 looks great - there are no big regressions and several big improvements There might be small regressions (~2%) from Postgres 15 and 16 to 17 but this benchmark was not setup to diagnose that. Builds, configuration and hardware I compiled Postgres versions 15.8, 16.4, 17beta3 and 17rc1 from source using  -O2 -fno-omit-frame-pointer . The servers are: small The server is named  v5 or Beelink SER7 here  and has 8 AMD cores with SMT disabled, 16G of RAM and uses Ubuntu 22.04 and ext4 with 1 NVMe device. large a  ax162-s  from Hetzner with 48 cores, AMD 128G RAM and AMD SMT disabled. It uses Ubuntu 22.04 and storage is ext4 using SW RAID 1 over 2 locally attached NVMe devices. More details on it  are her

This has results from the db_bench benchmarks for RocksDB on both a small and medium server using a database that is cached by RocksDB. Previous posts are here and here  with results for RocksDB 6.0 to 9.3. This has results up to version 9.6. tl;dr Bug 12038 arrived in RocksDB 8.6 and has yet to be fixed, but a fix arrives soon. This effects results on servers when the workload is IO-bound, buffered IO is used (no O_DIRET) and max_sectors_kb for storage is smaller than 1MB. The worst-case regression from 6.0 to 9.6 is ~20% but in most cases it is <= 10% and in a few cases I get more throughput in 9.6. Were I to begin using the hyperclock cache then results from modern RocksDB would be much better Hardware I tested on two servers: Small server SER7 - Beelink SER7 7840HS ( see here ) with 8 cores, AMD SMT disabled, a Ryzen 7 7840HS CPU, Ubuntu 22.04, XFS and 1 NVMe device. The storage device has 128 for max_hw_sectors_kb and max_sectors_kb. Medium server C2D - a  c2d-highcpu-32  ins