Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Really? Coming from PGSQL to a MySQL-only shop made me really miss PGSQL's performance. Sure, MySQL is faster on `select pk from tbl where pk=1`, but the second you get into complicated joins, including subqueries, or doing any analytics the performance is very random.

With pgsql, I can get a clear concise explain and if I disagree with what's happening (because I know exactly what my hardware is capable of) I can tune any query to be decently performant.

With mysql, you get... I mean explain is ok, but I wouldn't put it above that. "EXPLAIN ANALYZE" is my gold standard forever and ever. I even liked it more than SQL Server's equivalent; which is also fantastic.



I've used PostgreSQL, SQL Server, and MySQL.

In my experience, MySQL had the worst query optimizer of the three. By A LOT. Basically, anything but a simple select could suck very unnecessarily. Even for simple selects, MySQL messes up.

I've fixed more than performance issue by changing SELECT * FROM users WHERE key1 = 0 OR key2 = 5 into two queries and concatenating the results.


MySQL's lack of CTEs is particularly annoying. Even SQLite has supported them for some time now!

I've seen this cause MySQL query authors to use various workarounds that end up impacting the query performance negatively.


I suspect MySQL is used with more bare bones schemas, without as many SQL function and complex triggers, as it has worse support for those (IMO, as someone that used MySQL). This does have the side effect of making it very ORM friendly, and the more you rely on an ORM the less you care or even know what queries are being run under the covers.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: