From: Tom Lane <tgl@sss.pgh.pa.us>
To: L J Bayuk <ljb220@mindspring.com>
Cc: Nigel J. Andrews <nandrews@investsystems.co.uk>
Cc: pgsql-interfaces@postgresql.org
Subject: Re: pgin.tcl pg_exec_prepared slow (was: Released...)
Date: Mon, 05 Jul 2004 22:43:47 -0400
Message-ID: <14766.1089081827@sss.pgh.pa.us> (raw)
In-Reply-To: <20040706010731.GA15183@bxlbisnugqvi.mindspring.com>
References: <24110.1087945736@sss.pgh.pa.us>
<Pine.LNX.4.21.0406302310340.12226-100000@ponder.fairway2k.co.uk>
<20040706010731.GA15183@bxlbisnugqvi.mindspring.com>
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-interfaces@postgresql.org
Cc: tgl@sss.pgh.pa.us, ljb220@mindspring.com, nandrews@investsystems.co.uk
Subject: Re: pgin.tcl pg_exec_prepared slow (was: Released...)
In-Reply-To: <14766.1089081827@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox