Tom Lane wrote:
> John Lister <john.lister-ps@kickstone.com> writes:
>
>> Oliver Jowett wrote:
>>
>>> It would be an extra network round-trip on every query, and there's no
>>> requirement to prepare it early.
>>>
>>>
>> Just going through the code again and please correct me if i'm wrong,
>> but at the moment there is unnecessary network traffic/latency. Assuming
>> a PreparedStatement, every time execute is called, sendParse and
>> sendDescribePortal are called (the former checks if a server side
>> prepared statement has been created and aborts if so). Admittedly
>> sendParse is only called as many times as setPrepareThreshold is set to
>> (which admittedly may be as low as 1)
>>
>
> I think you're missing the cue that those are "send" operations. They
> don't wait for a response to come back. In fact, assuming that the JDBC
> driver is implemented the way I think, the actual data for both messages
> is expected to go out as a single network packet after the driver
> reaches the point of expecting a response.
>
I appreciate that the send operations (and responses) may be grouped
into a single packet, but i was thinking of the scenario (which i would
have thought is fairly common) where you prepare the statement and
execute it multiple times with different parameters...
This will result in the parse and describe(portal) commands being sent
twice as is (unless i set the prepare threshold to be 1). Admittedly,
this will probably not result in any extra packets as the total length
of all commands is likely to be less than the packet length (the query
size is likely to be the limiting factor here), but this causes extra
load on both the server and client - although maybe not enough to worry
about.
I was thinking that you could parse/describe the query just once.
I also accept that (for the binary transfer stuff) describing the
statement first would require an additional network packet or 2 as you'd
need to read the results before you could work out the bind..
JOHN
