Hi,
On 2018-03-28 09:59:34 -0400, Tom Lane wrote:
> Andres Freund <andres@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
