On 03/25/2013 08:24 PM, Nicholas White wrote:
> > Do you see the binary transfers activating for array receives if you run your prepared statement select in a loop?
> That's the behaviour I see, athough something's setting my m_prepareThreshold to 5 rather than 3. I'm essentially
usingpostgres as a persistent cache for my
> application server; when my app server starts it loads large amounts of data from postgres using a series of
select-*-from-xqueries. In order to minimise
> network I/O I'd ideally like a way to ensure I'm using the binary protocol from the very first query. Should I submit
anotherpatch that lets you configure this
> behaviour (either via a new JDBCUrl parameter or whether binaryTransfer is explicitly specified)?
I can't remember how the prepareTheshold goes. Is it so that even setting it to 1 (0 disables them) you still get real
preparedstatements (and at the same
time binary transfers) on the second execution. If you have an application that benefits from binary transfers on the
firstexecution then yes, we should add
an option to enable that behaviour. So another patch for that would be nice.
> Separately, do you know why this behaviour is the default? Is the binary encoding more expensive (either server-side
orclient-side) than text encoding the data?
It's not because of binary encoding, which is faster on both server and client side.
The current functionality tries to avoid the extra describe overhead (is it even a roundtrip?) for prepared statements
thatare only executed once (or very few
times), which is quite common in many applications that seem to use prepared statements also for one-shot cases.
PS. if you are concerned about binary array transfer performance I did some work last year to optimize the protocol for
arraysthat do not contain nulls.
Unfortunately there was never any resolution to the server side patches. The discussion got stuck on weather updates
withfeature flags, adding a minor version
number to the protocol or just wait for pg 10 to break the protocol is the correct way to go forward.
You can grab the server side + jdbc patches from here:
http://www.postgresql.org/message-id/4ECC186A.30709@nitorcreations.com
-Mikko