Re: Slowness of extended protocol

Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:

> Bruce Momjian <bruce(at)momjian(dot)us> writes:
> > On Sun, Jul 31, 2016 at 05:57:12PM -0400, Tom Lane wrote:
> >> In hindsight it seems clear that what a lot of apps want out of extended
> >> protocol is only the ability to send parameter values out-of-line
> instead
> >> of having to quote/escape them into SQL literals. Maybe an idea for the
> >> fabled V4 protocol update is some compromise query type that corresponds
> >> precisely to PQexecParams's feature set: you can send parameter values
> >> out-of-line, and you can specify text or binary results, but there's no
> >> notion of any persistent state being created and no feedback about
> >> parameter data types.
>
> > Do you want this on the TODO list?
>
> I didn't hear anyone say it was a silly idea, so sure.
>

Frankly speaking, it is not clear what this change buys.

Are you sure v3 cannot be tuned to reach comparable performance?

I do not like very much having a variety of "query modes".
For instance, when working with logical replication, extended queries are
not supported over the wire, that complicates client.
This particular issue delays merge of logical repilcation support to the
JDBC driver:
https://github.com/pgjdbc/pgjdbc/pull/550#issuecomment-236418614
<https://github.com/pgjdbc/pgjdbc/pull/550>

If adding one more "execute flavor" the things would get only worse, not
better.

Reusing parse state does indeed improve the performance in real-life
applications, so I would wonder if we can make current "extended" query
faster rather than implementing yet another protocol.

So while the request itself would definitely make sense if we had no
"v2/v3" protocols at all, however as we do have v2 and v3, it adding
"PQexecParams's
feature set" looks not that important.

Just in case, here are "protocol wanted features" as seen by client
applications (e.g. JDBC client):
https://github.com/pgjdbc/pgjdbc/blob/master/backend_protocol_v4_wanted_features.md

Vladimir