That said, if you're doing N-way joins with N big you probably want bitmap index support too, which is another thing missing in MySQL, although I've written libraries that, for certain specialized cases, can fake it.
I would love to see an example of this, given the same data, schema, similar tuning params, etc.
Any time you comment out a WHERE clause on a big table while performing an aggregate report, Postgres chokes.
Compared to InnoDB? You are incorrect, Postgres is faster, even for a raw count(*), even when comparing against the InnoDB plugin and not the ancient InnoDB builtin.
I have access to tuned TB+ DBs of both types and am happy to disprove any specific examples you can provide.
Though I tend to prefer Postgres don't get me wrong - MySQL has some advantages.
For raw pkey lookups, especially range selects against pkeys with lower amounts of concurrency InnoDB's speed is unmatched. It should be given that it is completely laid out on disk specifically for that to the detriment of other features.
MySQL's replication is extremely sturdy. On paper the older method (statement-based) sounds incredibly fragile but in practice it works extremely well and has been proven on countless projects. mmm makes it almost too easy to setup replication and failover.
I feel that MySQL stalled out for several years in the 5.0-5.1 period where poorly engineered features were bolted on to create a product with too many pathological cases that destroyed performance to keep track of. All these features were available but experience taught you to avoid most joins, avoid most subselects, avoid most usages of views, etc.
That said, v5.5 has a lot of nice improvements and can actually scale up to more than 8 cores (I've gotten linear improvement up to about 32 cores and that is what Oracle puts in their white papers as well). Percona and Facebook are releasing nice patches and branches, and forks like Drizzle are reaching GA and doing good things as well. So I think it is headed in the right direction again.