This is InnoDB's sweet spot really -- a mostly read-only in memory data set where the lookups are done primarily by PK. MySQL 5.5 can scale this kind of workload to 32 cores.
I'm pretty sure given this kind of workload MySQL will outperform PostgreSQL handily.
And PostgreSQL 9.2 will be able to scale this workload linearly to 64 cores. So while MySQL may or may not win it will certainly not "outperform PostgreSQL handily".
The key is that PostgreSQL 9.2 will be able to handle a 64 core workload, but current released versions of PG do not.
The fact is current versions of PG are unable to use more than 60% CPU on a 24 core machine. Do you know anyone who uses a dev version of an RDBMS in production?
I believe that MySQL 5.5 scales to 32 cores but not linearly, while PostgreSQL 9.1 caps at 24 cores. As I said in my last comment: I do not doubt much that MySQL would beat PostgreSQL 9.1, but it wont beat it "handily".
Why do you say this like it is impressive? Postgresql will scale to 32 cores with a real workload, and has done so for a few years. Mysql performance still tanks at 8 cores. It is very unlikely that mysql will be able to match postgresql for this workload, much less outperform it "handily".
No, it's not. The referenced article is talking about Postgres 9.2devel. Version 9.2 isn't out yet, and even if it was, it still wouldn't be true due to the clause "and has done so for a few years".
The lock manager bottlenecks that stopped PG from using more than 60% of the cpu power on a 24 core box were discovered a little less than a year ago.
You are making assumptions about one scenario based on limitations encountered in a very different scenario. The problems that occur around 24 cores occur on benchmarks consisting entirely of select statements against a single table. As I said, postgresql has scaled to 32 cores for real workloads for a few years. Real workloads have more than one table.
Your MySQL example isn't exactly relevant. It was in 2007, yet you said "MySQL still tanks at 8 cores". Furthermore it was on FreeBSD, with a flawed libpthread.
In terms of "real" workloads, I'm not going to bother getting into it, as this is quickly devolving in to a true Scotsman argument.
Instead of arguing pointlessly about it, maybe our energy would be better spent publishing some benchmarks.
