Re: About binaryTransfer.

Before the patch the functionality was (if binaryTransfer=true):
- prepared statements after prepareThreshold were done in binary mode
- forceBinary=true could be enabled to force all statements (prepared + one-shot) to be executed in binary mode (at
costof extra round-trip) 

After the patch in question (if binaryTransfer=true):
- All prepared statements have extra round-trip before on first use and are immediately in binary mode
- forceBinary=true can be enabled to force also one-shot statements to be executed in binary mode (at cost of extra
round-trip)

Since there are users that use prepared statements in one-shot way (prepare+execute+discard) the patch adds a mandatory
extraround-trip for them. 

As a side note: the forceBinary is meant only as a debug flag (used for example in pgjdbc tests), not for production
use.

So the only thing the before-state could not do was to use binary transfers for the first prepared statement execution.
Thisis because setting prepareThreshold=0 disables the prepare instead of preparing before first use. 

I propose we revert that patch and instead add support for prepareThreshold=-1 which would force prepare+describe to be
doneeven for the first execution. That would allow users to keep controlling the behavior instead of forcing binary
transfersimmediately? 
Alternatively we can separate the binary transfer logic from statement prepare threshold and add a separate
binaryThreshold.

-Mikko
________________________________________
From: pgsql-jdbc-owner@postgresql.org <pgsql-jdbc-owner@postgresql.org> on behalf of Tomonari Katsumata
<katsumata.tomonari@po.ntts.co.jp>
Sent: 21 February 2014 08:40
To: pgsql-jdbc@postgresql.org
Subject: [JDBC] About binaryTransfer.

Hi,

I have a peformance trouble with 9.3-1100 driver.
Running same application(*) with 9.2-1004 and 9.3-1100,
It does another behavior.
(*) Retrieving 9990 rows with preparedStatement.

9.2-1004:
Always flags = 16.
----
14:09:55.730 (1) simple execute,
handler=org.postgresql.jdbc2.AbstractJdbc2Statement$StatementResultHandler@8232a5d,
maxRows=0, fetchSize=0, flags=16
14:09:55.878 (1) simple execute,
handler=org.postgresql.jdbc2.AbstractJdbc2Statement$StatementResultHandler@34e671de,
maxRows=0, fetchSize=0, flags=16
----

9.3-1100
Repeatedly flags = 48 and 16.
The count of "flags=16" is same with 9.2-1004, so
"flags=48" is extra executing.
----
14:20:34.991 (1) simple execute,
handler=org.postgresql.jdbc2.AbstractJdbc2Statement$StatementResultHandler@19cdbc83,
maxRows=0, fetchSize=0, flags=48
14:20:34.992 (1) simple execute,
handler=org.postgresql.jdbc2.AbstractJdbc2Statement$StatementResultHandler@304b0cbc,
maxRows=0, fetchSize=0, flags=16
----

This change has caused by below commit.
https://github.com/pgjdbc/pgjdbc/commit/dbf76c2d662896c5703cf20d7362e1d061e1e43f

It seems that binarytransfer mode is good at dealing with
big-data(many columns?many rows?), but some packets are
sent/received for this function, right?

I want to make 9.3-1100 driver do old behavior like 9.2-1004.
What can I do ?

regards,
----------------
Tomonari Katsumata




--
Sent via pgsql-jdbc mailing list (pgsql-jdbc@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-jdbc