Re: Slowness of extended protocol

On Sun, Aug 7, 2016 at 6:11 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:

> I'm glad reducing the overhead of out-of-line parameters seems like an
> > important goal. FWIW, if as Vladimir seems to suggest, it's possible to
> > bring down the overhead of the v3 extended protocol to somewhere near the
> > simple protocol, that would obviously be a better solution - it would
> mean
> > things work faster here and now, rather than waiting for the v4
> protocol. I
> > have no idea if that's possible though, I'll see if I can spend some
> time on
> > understand where the slowdown comes from.
>
> That having been said, I don't really see a reason why we couldn't
> introduce a new protocol message for this without bumping the protocol
> version. Clients who don't know about the new message type just won't
> use it; nothing breaks. Clients who do know about the new message
> need to be careful not to send it to older servers, but since the
> server reports its version to the client before the first opportunity
> to send queries, that shouldn't be too hard. We could add a new
> interface to libpq that uses the new protocol message on new servers
> and falls back to the existing extended protocol on older servers. In
> general, it seems to me that we only need to bump the protocol version
> if there will be server-initiated communication that is incompatible
> with existing clients. Anything that the client can choose to
> initiate (or not) based on the server version should be OK.

That sounds right to me. As you say, the server version is sent early in
the startup phase, before any queries are sent to the backend, so frontends
know which server they're communicating with.

We could call this "protocol 3.1" since it doesn't break backwards
compatibility (no incompatible server-initiated message changes, but it
does include a feature that won't be supported by servers which only
support 3.0. This could be a sort of "semantic versioning" for the protocol
- optional new client-initiated features are a minor version bump, others
are a major version bump...

This new client-initiated message would be similar to query, except that it
would include the parameter and result-related fields from Bind. The
responses would be identical to the responses for the Query message.

Does this make sense?