Small Datum

One of my hobbies is testing open source DBMS for CPU regressions and for that I want to compare perf between old and new versions of the DBMS. Depending on the DBMS it can be a challenge to build the old DBMS with the current (modern) compiler toolchain.  Using open source frequently means compiling from source and compiling from source eventually means debugging a failed build. Alas, the proliferation of build tools means you are likely to be debugging a build tool you know little about. For me that included svn+MongoDB, cmake+MySQL, make/configure+MySQL, mvn+Linkbench, mvn+First_Robotics and make+RocksDB. Perhaps my debugging would be easier if there weren't as many build tools. Postgres might be an exception WRT compiling old versions - it works great. Alas, this isn't as easy with MySQL versions 5.6.51 and 5.7.39. Note that MySQL 5.6 reached end of life in 2021 but 5.7 doesn't reach that until next year. For MySQL 5.6, 5.7 and perhaps some 8.0 releases prior to 8.0.31,

This has results for the insert benchmark using Postgres, InnoDB and MyRocks. For an overview of the insert benchmark see here and here . Some information on the performance summaries generated by my test scripts is here . I used  small servers  and ran the test at low concurrency (1 or 2 threads) for cached and IO-bound workloads. The insert benchmark has several phases and the interesting phases are: insert-only without secondary indexes, insert-only with 3 secondary indexes and then range queries with rate-limited inserts. Performance reports are provided for: Postgres versions 12.11, 13.7, 14.6 and 15.1:  cached  and  IO-bound InnoDB 5.6.49, 5.7.35, 8.0.21 and 8.0.31:  cached  and  IO-bound MyRocks 5.6.35 and 8.0.28:  cached  and  IO-bound Disclaimer - I used a small server and will soon repeat this on larger servers and with more concurrency. tl;dr Postgres is boring: no CPU regressions from version 12 to 15 for cached and IO-bound  workloads. The insert benchmark found a CPU r

I am trying to understand why 4kb random reads from an SSD are about 2X slower when using a filesystem vs a raw device and this reproduces across different servers but I am only sharing the results from my home Intel NUCs . The symptoms are, the read response time is: ~2X larger per iostat's r_await for reads done via a filesystem vs a raw device (.04 vs .08 millisecs) ~3X larger per blkparse for reads done via a filesystem vs a raw device (~16 vs 50+ microsecs) Once again, I am confused. Is something below user land doing (if from-filesystem -> go-slow). In theory, if the D->C transition reported by blkparse includes a lot of CPU overhead from the filesystem then that might explain this, but the CPU per IO overhead isn't large enough for that to be true here. My test scripts for this are rfio.sh and do_fio.sh . Update - the mystery has been solved thanks to advice from an expert (Andreas Freund) who is in my Twitter circle, and engaging with experts I would never get