Index ordered and clustered tables are different. Postgres' CLUSTER command simply rebuilds the the index after sorting the underlying data, in a on-off, blocking, operation. That means further operations will slowly reduce the "sortedness" and that it can't be relied upon when correctness is relevant (e.g. to skip a sort step for an ORDER BY).
Real index ordered tables would be nice, but I don't see them in the near future.
> Odds are poor that there is such low-hanging fruit the PostgreSQL team simply ignores.
I'm not aware of any really low-hanging fruits that we know of. While I'd like to improve INSERT performance a bit more, I think at the moment real bottlenecks are elsewhere. I mean on a halfway good single server I can do ~240k INSERTS/sec, without pipelining and about 1100k with. That's not exactly nothing. With COPY instead of INSERTs you can do a lot more.
I think write performance can be a improved a fair bit, but it's not the low hanging fruit level anymore. The biggest things I know are 1) replacing the buffer mapping hash table with a lock free datastructure (radix tree is what I/we are experimenting with) 2) better cache replacement implementation, suitable for very large memory sizes with a high turnover 3) make buffer pins lock free (patch exists) 4) make relation extension scale better
> I'm thinking the article is accurate, even if it seems gloating to MySQL fans.
I wish we could all use a bit less adversarial tone in these kinds of discussions. Mysql does some things better. Postgres some others. For some others it's not yet clear which direction is better. Of course I personally prefer PostgreSQL, but that shouldn't make me blind that they got some things right that we didn't.
EDIT: Updated throughput number from 800k to 1.1 mio.