Re: About binaryTransfer.

Hi Dave,

I've misunderstood the behavior of this problem.
The main problem is that the Describe message is send/receive
repeatedly, if user don't want to do so.

The pull-request I've sent before(#124) didn't solve the problem.

Now, I fixed it and sent a new pull-request.
https://github.com/pgjdbc/pgjdbc/pull/128

Please check it!

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

(2014/02/23 9:34), Tomonari Katsumata wrote:
> 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
>>>
>>
>>
>