From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | John Lister <john(dot)lister-ps(at)kickstone(dot)com> |
Cc: | Oliver Jowett <oliver(at)opencloud(dot)com>, pgsql-jdbc(at)postgresql(dot)org |
Subject: | Re: Query preparation |
Date: | 2009-04-14 20:52:24 |
Message-ID: | 18961.1239742344@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-jdbc |
John Lister <john(dot)lister-ps(at)kickstone(dot)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.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | John Lister | 2009-04-14 21:10:08 | Re: Query preparation |
Previous Message | John Lister | 2009-04-14 20:29:00 | Re: Query preparation |