Re: About binaryTransfer.

Hi Mikko,

Thank you for the explanation.

I agree with your proposal adding prepareThreshold=-1.

If there are no objection, I'll do for it!

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

(2014/02/21 16:50), Mikko Tiihonen wrote:
 > 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 cost of 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 extra round-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. This is 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 done even
for the first execution. That would allow users to keep controlling the
behavior instead of forcing binary transfers immediately?
 > 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
 >
 >