Edit: As an example, one of the optimizations called out in this repo was submitted in October 2023. “Thank you for the report and contribution.” and then radio silence ever since.
https://bugs.mysql.com/bug.php?id=112737 https://www.percona.com/blog/what-oracle-missed-we-fixed-mor...
16. Why aren't these improvements merged into the official MySQL?
Optimizations have been recommended to the official team and have received acknowledgment. However, they are assigned low priority in official bug fixes. Simple optimizations may take considerable time to be integrated, while complex ones might never be implemented.
As a result, the decision was made to open-source the MySQL optimized version to ensure effective application in high-end scenarios.
Maybe these optimizations can let me avoid moving to Vitess for another year!
And if this sounds contrived, this is basically what happened with our hardware vs. software optimization situation. We could do wonders on a 1MHz chip with 2MB of RAM in the 1980s, but now we need literally many thousands of times that capacity just to boot our OS to an empty screen.
Every time hardware improved, software bloated up. Thus eventually we had so much disposable compute just for... again, literally... playing games and crypto scams, that we invented AI running on it. And now that AI is once again blowing up our energy needs.
All that, because hardware kept optimizing, software kept compensating by becoming worse, and thus new use cases revealed themselves that would be impossible before, but rather destructive to climate.
Having a cheaper, more available resource increases overall utilization of that resource.
Any reason why considering Vitess isn't exactly new and has been stable enough? Other than no need to introduce additional complexity unless absolutely necessary.
I know it's moving slower and in a lot of ways it's inferior to mysql, but at the same time that would make it even better to have some contributions like this.
Do not know about speed difference divergence though. I guess a speed run down would be interesting...
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.
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.
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
I find it curious that <https://github.com/google/mysql-tools/blob/02d18542735a528c4...> and yet <https://github.com/google/mysql-tools/blob/02d18542735a528c4...> says "diff -ruN base/client/mysqldump.c mysql40gpl/client/mysqldump.c"
I had no idea one could release patches of GPL software under an Apache license. That makes my head hurt.
[1] https://github.com/enhancedformysql/The-Art-of-Problem-Solvi...
For all i know there could be other methods in mysql at this point, but views is how people have been doing fine grained row permissions in mysql for decades.
I would read that blog post, because I am firmly in the "mysql/mariadb is for people who like mongo" camp but I like learning new things
While I was delighted to see that 11 no longer just straight-up throws input data in the trash, I get a lot of mileage out of transactional DDL which seems to still be a PG feature
docker run -d --name my -e MARIADB_ROOT_PASSWORD=sekrit docker.io/library/mariadb:11.4.7
docker exec -i my mariadb -psekrit mysql <<SQL
BEGIN;
CREATE TABLE just_kidding (pk int);
CREATE TABLE onoz (migrations are hard, yo);
ROLLBACK;
SQL
docker exec -i my mariadb -psekrit mysql <<SQL
SELECT count(1) FROM just_kidding;
SQL
count(1)
0
https://mariadb.com/kb/en/sql_modemssql/
https://mariadb.com/kb/en/sql_modeoracle/
which I would enjoy exploring more
You're essentially proving the upthread commenter's point here... the relevant setting is strict sql_mode, which has been available as an option for literally 20 years, and has generally been used by any serious MySQL/MariaDB shop for that whole time. Long ago it wasn't enabled by default out of the box, but it has been since MySQL 5.7 (released 10 years ago) and MariaDB 10.2 (released over 8 years ago).
> I get a lot of mileage out of transactional DDL which seems to still be a PG feature
Correct, MySQL and MariaDB do not support transactional DDL, and maybe never will. That's not a unique shortcoming though, as Oracle and SQLite don't support it either. MS SQL Server does support it, but if I recall correctly there are caveats depending on the isolation level in use.
Postgres clearly wins out on that feature, but as with everything in computing, it comes with serious trade-offs: a rather sub-par MVCC implementation [1], and lack of DDL support in logical replication [2].
I'm biased because I work in this space, but IMO it's easy to live without transactional DDL in MySQL/MariaDB if you pair a good schema management system (which allows you to test and lint DDL) with an online schema change tool (which allows you to throw away the shadow table if something goes wrong). And generally you shouldn't be running DDL by hand directly in prod anyway...
[1] https://www.cs.cmu.edu/~pavlo/blog/2023/04/the-part-of-postg...
[2] https://www.postgresql.org/docs/current/logical-replication-...
Postgres is far more flexible and capable, but it requires a lot of care and feeding, as well as deeply reading its docs to get the most out of it. MySQL is good enough for 99.99% of tech companies, and requires little to no maintenance in comparison.
Both will require you to know how to design a performant schema and query, however.
MySQL has supported Stored Procedures since version 5.
That was 20 years ago.
No offense but I'm always curious about how people solidify easily verifiable missinformation as facts. I'm assuming most spread it out of ignorance, not malice.
I feel that as soon ChatGPT & friends are going to start with native advertising, a whole new market will open up. And it won't be good.