Re: About binaryTransfer.

Hi Dave,
I sent a Pull Request about this.
https://github.com/pgjdbc/pgjdbc/pull/124

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

2014-02-21 21:09 GMT+09:00 Dave Cramer <pg(at)fastcrypt(dot)com>:

> Please submit a Pull Request
>
> Dave Cramer
>
> dave.cramer(at)credativ(dot)ca
> http://www.credativ.ca
>
>
> On Fri, Feb 21, 2014 at 3:57 AM, Tomonari Katsumata <
> katsumata(dot)tomonari(at)po(dot)ntts(dot)co(dot)jp> wrote:
>
>> 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(at)postgresql(dot)org <pgsql-jdbc-owner(at)postgresql(dot)org>
>> on behalf of Tomonari Katsumata <katsumata(dot)tomonari(at)po(dot)ntts(dot)co(dot)jp>
>> > Sent: 21 February 2014 08:40
>> > To: pgsql-jdbc(at)postgresql(dot)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(at)8232a5d,
>> > maxRows=0, fetchSize=0, flags=16
>> > 14:09:55.878 (1) simple execute,
>> > handler=org.postgresql.jdbc2.AbstractJdbc2Statement$
>> StatementResultHandler(at)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(at)19cdbc83,
>> > maxRows=0, fetchSize=0, flags=48
>> > 14:20:34.992 (1) simple execute,
>> > handler=org.postgresql.jdbc2.AbstractJdbc2Statement$
>> StatementResultHandler(at)304b0cbc,
>> > maxRows=0, fetchSize=0, flags=16
>> > ----
>> >
>> > This change has caused by below commit.
>> > https://github.com/pgjdbc/pgjdbc/commit/dbf76c2d662896c5703cf20d7362e1
>> d061e1e43f
>> >
>> > 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(at)postgresql(dot)org)
>> > To make changes to your subscription:
>> > http://www.postgresql.org/mailpref/pgsql-jdbc
>> >
>> >
>>
>>
>>
>>
>> --
>> Sent via pgsql-jdbc mailing list (pgsql-jdbc(at)postgresql(dot)org)
>> To make changes to your subscription:
>> http://www.postgresql.org/mailpref/pgsql-jdbc
>>
>
>