Small Datum

My primary goal with the benchmarks I run has been to identify performance regressions, especially ones that can be fixed to make open source databases better. And so I focus on comparing old and new versions of one DBMS at a time to identify where things get better or worse. But here I compare Postgres with MySQL (InnoDB & MyRocks) to show that neither is the best for the Insert Benchmark -- all are good, but none are perfect. The per-DBMS results are here for Postgres , InnoDB and MyRocks . Those posts also have links to the configurations and builds that I used. This post shares the same result but makes it easier to compare across DBMS.  Results here are from a small server (8 cores) with a low concurrency workload (1 client, <= 3 concurrent connections). Results from a larger server are pending and might not be the same as what I share here. Summary of throughput for the IO-bound workload Initial load in key order (l.i0) Postgres is fastest Write-only with secondary index

While trying to explain a Postgres performance problem I repeated the Insert Benchmark on a small server for MyRocks from MySQL 5.6 and 8.0. This post explains those results. The previous report for a cached workload is here . tl;dr Disclaimers The low-concurrency results here are worse than the results from a bigger server with more concurrency because the result here depends more on CPU overheads and MySQL keeps on growing code paths, while on the bigger server the cost from new CPU overheads is offset by other improvements. Some of the regressions here are similar to what I measure for InnoDB and the problem is likely code above the storage engine layer. For MyRocks 8.0.28 compared to 5.6.35 Results for most benchmark steps aren't surprising and MyRocks 8.0.28 gets between 80% and 95% of the throughput compared to MyRocks 5.6.35 Results for the qr1000.L6 benchmark step with the IO-bound workload are odd. MyRocks 8.0.28 gets only 39% of the throughput compared to MyRocks 5.6.35.

While trying to explain a Postgres performance problem I repeated the Insert Benchmark on a small server for InnoDB from MySQL 5.6, 5.7 and 8.0. This post explains those results. Previous reports are here for cached and IO-bound workloads and the results here are similar. tl;dr Disclaimer - the low-concurrency results here are worse than the results from a bigger server with more concurrency because the result here depends more on CPU overheads and MySQL keeps on growing code paths, while on the bigger server the cost from new CPU overheads is offset by other improvements. There are significant regressions from 5.6 to 5.7 and again from 5.7 to 8.0 Build + Configuration This report has results for InnoDB with MySQL 5.6.51, 5.7.44 and 8.0.36. The cz10a_bee config was used and they  are here . The Benchmark The benchmark is run with 1 client. It is  explained here  and was run in two setups cached - database has 30M rows and fits in memory IO-bound - database has 800M rows and is large

Last year I spent much time trying to tune the Postgres configs I use to improve results for the Insert Benchmark . While this was a good education for me I wasn't able to get significant improvements. After writing about another perf problem with Postgres (optimizer spends too much time on DELETE statements in a special circumstance) I revisited the tuning but didn't make things significantly better. The results here are from Postgres 16.2 and a small server (8 CPU cores) with a low concurrency workload. Previous benchmark reports for Postgres on this setup are here for cached and IO-bound runs. tl;dr I have yet to fix this problem via tuning The Problem The performance problem is explained here and here . The issue is that the optimizer spends too much time on DELETE statements under special circumstances. In this case the optimizer can read from the index to determine the true value for the min or max value of the column referenced in the WHERE clause and when there are t