🔥 The DB Grill 🔥

Heh. Well, well, well. I just finished my cup of coffee—the kind that could strip paint, not one of your half-caf soy lattes—and stumbled across this... this masterpiece of modern analysis. A truly breathtaking bit of bean-counting, son. You've compiled every version from source, you've got your little my.cnf files all lined up, and you've even connected via a socket to avoid the dreaded SSL. My, how clever. It’s a level of meticulousness that warms my old, cynical heart.

It’s just wonderful to see you kids rediscover the scientific method to arrive at a conclusion that we, the greybeards of the server room, knew in our bones: "progress" is just another word for "more layers of abstraction that slow things down."

You’ve produced a lovely little table here, all full of pretty colors. It's a real work of art.

The summary is: ...modern MySQL only gets ~60% of the throughput relative to 5.6 because modern MySQL has more CPU overhead

Oh, you don't say? More CPU overhead? You mean to tell me that after a decade of piling on features that nobody asked for—JSON support, window functions, probably an integration with a blockchain somewhere—the thing actually got slower? I am shocked. Shocked, I tell you.

Back in my day, if you shipped a new version of the payroll system that ran 40% slower, you weren't writing a blog post. You were hand-typing your resume after being walked out of the building by a man named Gus who hadn't smiled since the Truman administration. We didn't have "CPU overhead." We had 8 kilobytes of memory to work with and a stack of punch cards that had to be perfect, or the whole run was shot. You learned efficiency real quick when a typo meant staying until 3 AM re-punching a card.

I must commend your rigorous testing on the l.i0 step. A clean insert into a table with a primary key. A foundational, fundamental function. And the throughput drops by 40%. It’s a bold strategy, to make the most basic operation of your database perform like it's calculating pi on an abacus. We had that figured out on DB2 on a System/370 back in '85. It was called a "batch job," and I assure you, the next version didn't make it slower.

But let’s not be entirely negative! Your chart clearly shows a massive improvement in l.x, creating secondary indexes. A 2.5x speedup! Hallelujah! So, while the initial data load crawls and the queries gasp for air, you can build the scaffolding for your slow-as-molasses lookups faster than ever before. It’s like putting racing stripes on a hearse. A triumph of modern engineering, to be sure.

And the query performance... ah, the queries.

• qr100... regression.
• qp100... bigger regression.
• qr500... regression.
• qp500... bigger regression.
• ...and so on.

It’s a veritable parade of performant poppycock. You're telling me that with an 8-core processor and 32 GIGABYTES of RAM—a comical amount of power, by the way; we used to run an entire bank on a machine with less memory than your phone's weather app—it chokes this badly? What are all those CPU cycles doing? Are they thinking about their feelings? Contemplating the futility of existence? We used to write COBOL that was more efficient than this, and COBOL is just a series of angry shouts at the machine.

It's just the same old story. Every few years, a fresh-faced generation comes along, reinvents the flat tire, and calls it a paradigm shift. They add so many digital doodads and frivolous features that the core engine, the thing that's supposed to just store and retrieve data, gets buried under a mountain of cruft.

So thank you, kid. Thank you for this wonderfully detailed, numerically sound confirmation of everything I've been muttering into my coffee for the last twenty years. You’ve put data to my disappointment.

Now if you'll excuse me, I think I hear a tape drive calling my name. At least when that breaks, you can fix it with a well-placed kick.