4 ms·

Hey at least it throws a warning on the bogus date conversion (MySQL warnings should almost always be treated as fatal errors). The thing that kills me with My

by eli 13y ago

Hey at least it throws a warning on the bogus date conversion (MySQL warnings should almost always be treated as fatal errors). The thing that kills me with MySQL (technically it's with InnoDB-based storage enginges in MySQL) are the subtle quirks. Like the thing where it insists on writing temporary tables to disk if you do a query that selects TEXT or BLOB fields. Even if they could have easily fit in memory, it's not smart enough to be able to determine that with variable length fields. A very non-obvious performance killer unless you're specifically looking for it.

deleted 13y ago
[deleted]
jacques_chester 13y ago
I run a small Wordpress network. MySQL's insistence on going to disk for joins on tables with a TEXT field (even if the query doesn't touch those fields) is probably the major performance bottleneck.
- e12e 13y ago
  Ouch. Thanks for the explicit heads-up. I generally stay with PostgreSql, but I honestly thought most of these things were "fixed" in recent versions of MySQL (and assumed my subconcious dislike of MySql was at least partly irrational/rooted in Ancient and Outdated Lore). I guess not: http://dev.mysql.com/doc/refman/5.7/en/internal-temporary-tables.html http://dev.mysql.com/doc/refman/5.7/en/internal-temporary-ta... I'm not sure what the status of TEXT-fields are in mariadb: https://mariadb.com/kb/en/optimizing-string-and-character-fields/ https://mariadb.com/kb/en/optimizing-string-and-character-fi...
  - eli 13y ago
    I tried MariaDB about a year ago and it had the same problem. It's possible it's been fixed since. I personally prefer the Percona fork of MySQL, which has some performance tweaks yet is basically a 100% drop-in replacement.
  - jacques_chester 13y ago
    > Thanks for the explicit heads-up. It took me a long term to learn this one. I suppose if I'd read the MySQL docs from cover to cover I would've found it earlier. One other problem that popped up was ignoring indexes on tables with TEXT fields during joins, which was a planner weakness. I understand it was fixed in 5.6; I'm waiting for the Percona version to stabilise before I upgrade.

by eli 13y ago

deleted 13y ago

[deleted]

jacques_chester 13y ago

I run a small Wordpress network. MySQL's insistence on going to disk for joins on tables with a TEXT field (even if the query doesn't touch those fields) is probably the major performance bottleneck.

e12e 13y ago
Ouch. Thanks for the explicit heads-up. I generally stay with PostgreSql, but I honestly thought most of these things were "fixed" in recent versions of MySQL (and assumed my subconcious dislike of MySql was at least partly irrational/rooted in Ancient and Outdated Lore). I guess not: http://dev.mysql.com/doc/refman/5.7/en/internal-temporary-tables.html http://dev.mysql.com/doc/refman/5.7/en/internal-temporary-ta... I'm not sure what the status of TEXT-fields are in mariadb: https://mariadb.com/kb/en/optimizing-string-and-character-fields/ https://mariadb.com/kb/en/optimizing-string-and-character-fi...
- eli 13y ago
  I tried MariaDB about a year ago and it had the same problem. It's possible it's been fixed since. I personally prefer the Percona fork of MySQL, which has some performance tweaks yet is basically a 100% drop-in replacement.
- jacques_chester 13y ago
  > Thanks for the explicit heads-up. It took me a long term to learn this one. I suppose if I'd read the MySQL docs from cover to cover I would've found it earlier. One other problem that popped up was ignoring indexes on tables with TEXT fields during joins, which was a planner weakness. I understand it was fixed in 5.6; I'm waiting for the Percona version to stabilise before I upgrade.