"Would it be necessary to modify the wire protocol to support multiple query/result-set combinations per server round-trip? That is, to be able to send a hundred different queries (each with a different number and type of columns in the result set) and receive a hundred different results all in a single network round-trip? That is a feature supported by some other databases that can have an order-of-magnitude effect on the performance of high-latency installations (satellite, etc.)."
I did a little research into this and it seems that we can already do this, sort of. See the following:
postgres=# select 1; select 'two'; select 'three'; select 4;
?column?
----------
1
(1 row)
?column?
----------
two
(1 row)
?column?
----------
three
(1 row)
?column?
----------
4
(1 row)
This will avoid the round trip. However there is a limitation. If these were tables, the server would only send the metadata of the last SELECT. The metadata being things such as table description, and number of rows returned. So if you return data from 4 tables, you are only going to know what to do with the last of the tables returned.
So it appears that the wire protocol does indeed support the ability to send multiple sets back but the server / libpq does not support sending multiple sets with isolated metadata.
The benefit of supporting this could be huge. Consider in a web word you can often end up calling dozens if not hundreds of queries for a single page draw. A network round trip on its own is not expensive but if you add up 30 or 200 of them, the performance degradation adds up quickly. This is especially true when you consider that they each have their own overhead with the server processing the query.