Re: pgin.tcl pg_exec_prepared slow (was: Released...)

L J Bayuk <ljb220@mindspring.com> writes:
> The delay we are seeing (about 40 ms) is from the time the client sends the
> Bind message to PostgreSQL until it gets a TCP ACK back. (It should get
> a BindComplete message back, but the backend does't flush after sending
> this - no pq_flush() at the end of exec_bind_message(). Hello, Tom, is this
> a bug?

No.  If you wanted a flush just there, send a Flush message.  But AFAICS
the only reason why you'd do that is if you needed to look at the
BindComplete before sending your next message --- which you do not.

> pgin.tcl sets its Tcl connection socket channel to "unbuffered",
> which means each PostgreSQL message it sends will be go into the TCP
> buffers immediately, since each message is written in a single "puts".

This is certainly bogus.  A good implementation would arrange to flush
the TCP outbound queue immediately after sending either a Flush or a
Sync message --- and *no place else*.  Those are exactly the points
where you are starting to wait for a backend reply.  More frequent
flushing simply results in more separate network packets, which is not
a win.  Also, if you haven't sent one of these message types, you are
not entitled to expect any immediate reply (which is essentially what's
happening with pgin.tcl, evidently).

The V3 protocol is designed around the assumption that each side will
batch multiple logical messages into single network packets whenever
possible.  If you don't do this, it's not surprising that performance
sucks :-(

The reason error recovery is defined as doing skip-to-Sync is exactly
so that you can shove off a batch of messages without having first
checked the results of the earlier messages.
        regards, tom lane