Where database blog posts get flame-broiled to perfection
Well, isn't this special. A whole dissertation on how the newfangled MySQL is finally catching up to... itself from ten years ago, but only when the wind blows west on a Tuesday. I have to applaud the sheer effort here. All these charts and colors... it's like a science fair project, but with more context switching.
It's just wonderful to see that "modern MySQL has large improvements for write-heavy benchmark steps because it reduces mutex contention." Bravo. It's like watching a toddler discover their own feet. Back in my day, we called this "decent locking." You know, the kind of thing DB2 was doing on a System/370 mainframe circa 1985 while your parents were listening to synth-pop. You kids create a dozen new locks, trip over them for a decade, and then pat yourselves on the back for finally cleaning up the mess you made. We didn't have "mutex contention," we had well-defined batch windows and a healthy fear of the system operator who'd come find you if your JCL job stepped on the CICS region. This isn't an improvement; it's a long, painful, and very public journey back to common sense.
And then we get to the flip side. My, oh my.
modern MySQL does worse than 5.6.51 on read-heavy steps, from new CPU overhead
Let me get this straight. You took a perfectly good engine, bolted on a bunch of new features that nobody asked for, and now it runs reads slower? Spectacular. That's like trading in your trusty pickup truck for a sports car that can't haul lumber. You've made it faster for one specific drag race down a perfectly straight road, but now it's useless for actual work. We used to have to justify every single CPU cycle to the bean counters. If I had turned in a change that resulted in a "1.5X larger" CPU-per-query, I'd have been escorted out of the data center before the tape backup finished its nightly run. These days you just throw more cores at it and call it "progress."
And the horse race with Postgres is just the cherry on top of this melted sundae. I do so enjoy seeing the young'uns argue over which of their toys is shinier. It seems Postgres is faster, except when it decides to take a little nap mid-transaction. You call it "variance and stalls"; I call it unpredictable, which is the last thing you want from a database. Reminds me of the time our tape library's robotic arm got stuck. The system was "stalled," alright. We fixed it with a bent coat hanger and a stern warning. You kids just write another blog post about "MVCC debt." We had REORG jobs. We ran them on Sunday at 3 AM. We didn't give it a cute name like it's a student loan we're trying to ignore.
It's all so very... thorough. All these benchmark steps—l.i2, qr500, qp1000—it looks like my bingo card from last week. You've spent weeks compiling every version from source, tweaking config files, and generating gigabytes of data to prove:
Groundbreaking stuff. Truly.
Just you wait. Give it another five years. They'll "solve" this read regression with a revolutionary new feature called the "Optimized Query Path." They'll write a hundred more blog posts about it. And when you peel back all the layers of marketing hype and JSON wrappers, you'll find it's just a poorly implemented hash join that was a standard feature in every relational database thirty years ago.
Mark my words, this whole house of cards is going to come down. The pendulum will swing back, and they'll trade all this "concurrency" for stability. Call me when you're ready to put your mission-critical data on a system that doesn't treat performance like a roll of the dice. I'll be in the server room, listening to the hum of the machines that actually work.