3 ms·
I honestly find MySql much simpler to use, create replication architectures, fix problems and use in general. And its not like you switch to Postgres and your
by exabrial 3y ago
I honestly find MySql much simpler to use, create replication architectures, fix problems and use in general.
And its not like you switch to Postgres and your indexes are 10x faster.
Postgres does seems to be marginally faster in some edge cases, but with it you have to learn a whole host of weird slash commands, the tooling just isn’t that great, and setup is unbelievably complicated compared to MySql and heavily heavily intertwined with the host os.
The real advantage Postgres had is some cool party tricks (like pivot functions, super handy for prepping data for Ml) but those being non ansi means you are flirting with disaster if they ever change or go away. Backups on MySql are also not a great affair… xtrabackup is marginally ok but requires some intense scripting. (Honestly I question the usefulness of backups anyway, I think slow replicas are probably the was to go).
It’s certainly not bad, but it’s also not like it isn’t without a myriad of rough spots.
- luciusdomitius 3y ago"SQL Error (1064): You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax near '' at line 21." when line 21 is 175 characters long. also, the fact that anything other than InnoDB is barely real ACID. also, the stuck development and lack of support for json, uuid and many other things. mysql being user-friendly (and especially beginner-friendly) is a massive hoax.
- aerzen 3y agoThis should instead be something like this: SQL Error (1064): 20 | 21 | ...ROM my_table JOIN other_table ON GROUP BY 22 | ^^^^^ This should not be hard. Both MySQL and Postgres do have the span of the parsing error and they do have the original query somewhere.
- anarazel 3y agoJust because I spent a few hours in the postgres parser guts lately: Postgres doesn't quite have the span of the error, just a single location :). We can of course measure the length of the token at the error point, but that isn't quite the same, as the cause of the error does not have to be a single token. postgres[122581][1]=# SELECT * FROM kdjfkdj; ERROR: 42P01: relation "kdjfkdj" does not exist LINE 1: SELECT * FROM kdjfkdj; ^