Idea: do use unnamed statements for extended query requests if feasible.

[fritshoogland-yugabyte]

All query methods except simple_query and batch_execute use the postgres extended query protocol.

The extended query protocol implementation of rust-postgres currently performs execution in 3 network roundtrips:

1. Parse, which creates a "named statement"/"prepared statement"
2. Bind and Execute, which performs the planning and execution of the statement
3. Close, which removes the prepared statement.

This can be reduced to 2 network roundtrips by not performing the prepared statement creation.

When an extended query statement is not prepared or named, it will use a so-called 'unnamed statement'. An unnamed statement essentially performs a lot of the same work of a named statement, with the striking difference that the unnamed statement does not need to be closed, and is automatically destroyed by the next parse or simply query execution.

There are two cases known to me currently that requires a named statement/prepared statement to exist:

• When a statement is explicitly prepared.
• When statements are pipelined, these have to be named in order to guarantee taking the correct query.

As far as I know currently in all other situations an unnamed statement would work fine.

Reference: https://github.com/sfackler/rust-postgres/issues/1017

[sfackler]

One thing to keep in mind is that statements are asynchronously closed, and if there's other active work on the connection they'll be folded into that outbound TCP request.

If it does turn out to still be useful, I think we can probably handle this by just tracking the state of "is the unnamed statement in use" - that way pipelined statement execution will be able to fall back to named statements when needed but it'll be able to avoid the extra close otherwise.