That said, I'm generally more frustrated when using MySQL than when using PG. Here's a sample of the problems I've encountered from using both MySQL and PG. I haven't updated my list in a while now - please feel free to correct me on things - but hopefully it's a little more illustrative than that Wikipedia feature matrix, and a little more specific to MySQL vs. PG. (This list is a cleaned-up selection from my notes wiki at http://yz.mit.edu/notes/Hackery.)
No referential integrity.
No constraints (CHECK).
No sort merge join, let alone hash-join. http://www.dbms2.com/2008/07/10/how-is-mysqls-join-performan..., http://www.mysqlperformanceblog.com/2006/06/09/why-mysql-cou...
Generally poor at analytical workloads, since it's designed for transactional workloads.
Can't reopen TEMP table - WTF? (Still not fixed!) http://bugs.mysql.com/bug.php?id=10327
Multiple storage engines has always restricted progress: http://www.mysqlperformanceblog.com/2010/05/08/the-doom-of-m... (PG also supported multiple storage engines in 80s, then concentrated on one)
No WITH clause: http://stackoverflow.com/questions/324935/mysql-with-clause
Crappy errors: “Incorrect key file for table ‘stock’; try to repair it” on “alter table stock add constraint pk_stock primary key (s_w_id, s_i_id);” where stock is in InnoDB (which has no “repair table”) means I have no /tmp space (no Google answers)
Crappy EXPLAIN output - somewhat better when using the visual-explain tool from Percona.
InnoDB auto-extends ibdata1 file; only way to trim (garbage collect) is dumping and loading.
Scoping is broken:
mysql> create table t(a int, b int); Query OK, 0 rows affected (3.30 sec)
mysql> select a, (select count(*) from (select b from t where a = u.a group by b) v) from t u;
ERROR 1054 (42S22): Unknown column ‘u.a’ in ‘where clause’
“InnoDB is still broken…Just last week we had to drop/re-create an InnoDB-table in one project because it would not allow to add an index anymore, no matter what we tried…Mysql::Error: Incorrect key file for table 'foo'; try to repair it: CREATE INDEX [...]” http://news.ycombinator.com/item?id=2176062
MySQL only recently got such things as per-statement triggers and procedural language support.
MySQL has only its own internal auth system, whereas PG supports a wide array of auth providers.
PG has more supple ALTER TABLE implementation.
MySQL doesn’t support ASC/DESC clauses for indexes http://explainextended.com/2010/11/02/mixed-ascdesc-sorting-...
Optimizer only recently started working properly with certain subqueries
OK documentation, but still considerably unpolished compared to PG's. Random omission: auto_increment jumps up to next power of 2 but inconsistently across versions (platforms?).
(Older issue, not sure if it's still relevant) Crappy concurrency, >3 cores sucks vs PG: http://spyced.blogspot.com/2006/12/benchmark-postgresql-beat...