Sort of wild that a small improvement to relay log processing could almost certainly offset one’s entire lifetime of carbon. I mean, I’m genuinely happier with a tiny latency reduction but it’s still wild the scale at which MySQL operates.
Maybe these optimizations can let me avoid moving to Vitess for another year!
Question: Does any of this optimizations apply to MariaDB?
Is there somewhere I could read about the JOIN performance degradation in detail?
EDIT: I missed that the authors wrote a GitHub book, including some descriptions of the problem(s): https://enhancedformysql.github.io/The-Art-of-Problem-Solvin...
Side note: One downside of ChatGPT generated documentation (assuming this was written in conjunction with an LLM) is that humans tend to be a little less verbose.
I have been trying to Submit MySQL news to HN but never reached the front page.
After how many years they have finally released 9.0 and are now at 9.3. I wonder how many of problem stated in the list is still true.
At least Vitess still get continuous development.
> 14.7MB
You know, a patch file can individually address each upsteam file it intends to modify, right? I presume someone who wants to casually read them would need to fork the repo, cut up the ginormous .patch file into the 2361 individual patches for ease of reading or deep-linking
I also just for-real don't understand how in the universe a ~15MB text file against an open source _git hosted_ project is a sane way of delivering value. Not a single time in the readme did they say why $(git diff origin/tags/8.0.42...HEAD > yolo.patch) was the chosen delivery mechanism
Patches to MySQL are nothing new, but who's behind this patch set?
Curious, Is there an easy way to do row-level and field-level security in MySQL?
Do they have stored procedures yet?
Why isn't this being upstreamed? I don't feel comfortable using some random patch someone found on github...