The benchmarking methodology is rather simplistic, true :) And I kinda wish he'd said things like "it's designed to be the most robust, reliable, and scalable disk-based RDBMS system" rather than simply "the fastest". People don't buy Oracle thinking it's fast. They buy Oracle thinking it will never bite them in the ass.
Folks who get bad numbers with PG frequently are using default configuration values, in particular the default value of 64 blocks of shared buffer cache. Also PG 7.1 gives us about a 10x improvement in raw insertion speed, due to the addition of REDO logging, so it's not clear that InnoBase is actually faster than PG 7.1 from his example.
Monty's published benchmarks were achieved by configuring MySQL in order to improve performance, i.e. not in its "out of the box" configuration. His PG numbers were run using default values. That was one of the things that caused me to think of him as being somewhat sleazy - particularly when he defended the practice.
The speed of the MySQL interpreter is partly due to the fact that it does very little optimization. Simple queries have always been fast in MySQL, but its performance on queries with complex joins on several tables has always been poor. Monty's benchmarks have always emphasized simple queries.
PG has a storage manager abstraction, but it's at a lower level than the abstraction in MySQL. The tuple storage format's pretty much hard-wired, so it wouldn't really be possible to drop the InnoBase backend into PG at this level.
On the other hand the parser and semantic analyzer present another layer one could plug into. It's not as cleanly defined and frankly the PG parser's a royal kludge and an ugly mess anyway.
Of course, before doing so one would needs to ask whether or not there's actually any thing inherently wrong with the PG backend in the first place. I don't think there is, myself.
