Re: pgin.tcl pg_exec_prepared slow (was: Released...) - Mailing list pgsql-interfaces

From L J Bayuk
Subject Re: pgin.tcl pg_exec_prepared slow (was: Released...)
Date
Msg-id 20040712013304.GA574@bxlbisnugqvi.mindspring.com
Whole thread Raw
In response to Re: pgin.tcl pg_exec_prepared slow (was: Released...)  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: pgin.tcl pg_exec_prepared slow (was: Released...)  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-interfaces
On Fri, Jul 09, 2004 at 08:07:56PM -0400, Tom Lane wrote:
> L J Bayuk <ljb220@mindspring.com> writes:
> > I just haven't decided
> > whether to flush before reading, or flush after all messages that need a
> > response (I think: Startup, PasswordMessage, Query, Sync, CopyDone, and
> > FunctionCall are the ones I use).
> 
> You seem to have quite missed my point.  If you decide to flush on the
> basis of flush-after-certain-message-types-are-sent, then the types to
> flush after are precisely Sync and Flush.  If you think you want
> something different, you are wrong and should think again (or more
> likely, insert Flush messages into the outgoing stream at the places
> where you want a flush to occur).  There is no point in flushing after
> any other message type because the backend won't flush its response.
>...

Yes, I must be missing your point, unless you are talking only about the
Extended Query mode. Surely outside of Extended Query mode (Startup, Basic
Query mode, Function Call) the client must flush output after (at least)
the messages I listed above. That's what I get from the protocol
documentation, what works in practice, and network traces.


pgsql-interfaces by date:

Previous
From: Tom Lane
Date:
Subject: Re: pgin.tcl pg_exec_prepared slow (was: Released...)
Next
From: Tom Lane
Date:
Subject: Re: pgin.tcl pg_exec_prepared slow (was: Released...)