Hi, On 2018-03-28 09:59:34 -0400, Tom Lane wrote: > Andres Freund <and...@anarazel.de> writes: > > A few random, very tired, points: > > > - consolidated message for common tasks: > > - (bind, [describe?,] execute) to reduce overhead of prepared > > statement execution (both in messages, as well as branches) > > - (anonymous parse, bind, describe, execute) to make it cheaper to > > send statements with out-of-line parameters > > I do not see a need for this; you can already send those combinations of > messages in a single network packet if you have a mind to.
The simple protocol right now is *considerably* faster than the extended protocol. The extended protocol sends more data overall, we do more memory context resets, there's more switches between protocol messages in both backend and client. All of those aren't free. https://www.postgresql.org/message-id/12500.1470002232%40sss.pgh.pa.us I've previously wondered whether we can peek ahead in the stream and recognize that we got a bind/describe/execute or parse/bind/describe/execute and execute them all together if all the necessary data is there. To avoid new protocol messages. > Your other points are sound, except I have no idea what this means: > > > - nested table support Yea, not the most descriptive... Returning multiple different resultsets from a function / procedure. Inability to do so is a serious limitation of postgres in comparison to some other language with procedures. Greetings, Andres Freund
