I think it would have been even faster if they'd test with SQL Server because you can do things with SQL Server that you simply cannot do in PG such as stored procedures that return multiple resultsets, which saves a ton of round-trips.
You can do even more advanced stuff in Postgres, but they've changed the rules to dissalow it since it much more faster than the the current best ones. Something about being fair to other frameworks...
> Can you request multiple heterogeneous result-sets from PG now, with something that looks like a stored procedure?
Not prettily. You can return cursors, you can use json etc, ...
But you can pipeline SQL statements. I.e. just send N SQL statements (including bind parameters etc, the protocol is the same) without waiting for results, and then process the results as they come in. If you want to avoid latency penalties that makes much more sense in my opinion than having to wrap multiple statements in a function.
