Re: About binaryTransfer.

From: Dave Cramer <pg(at)fastcrypt(dot)com>
To: Tomonari Katsumata <katsumata(dot)tomonari(at)po(dot)ntts(dot)co(dot)jp>
Cc: Tomonari Katsumata <t(dot)katsumata1122(at)gmail(dot)com>, Mikko Tiihonen <Mikko(dot)Tiihonen(at)nitorcreations(dot)com>, "pgsql-jdbc(at)postgresql(dot)org" <pgsql-jdbc(at)postgresql(dot)org>
Subject: Re: About binaryTransfer.
Date: 2014-04-15 00:05:53
Message-ID: CADK3HHKGj-qdSQS0ZCBZikN8GDp1JRqC3RbnVi0Zqzr9EWVx2Q@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-jdbc

Tomonari,

I pulled this into master. I'm not quite sure I want this back patched into
9.3 though. This is new behaviour.

Dave Cramer

dave.cramer(at)credativ(dot)ca
http://www.credativ.ca

On 3 April 2014 04:37, Tomonari Katsumata
<katsumata(dot)tomonari(at)po(dot)ntts(dot)co(dot)jp>wrote:

> Hi Dave,
>
> Did you check my pull-request?
> https://github.com/pgjdbc/pgjdbc/pull/128
>
> I don't want to use 9.2-1004 Driver, because it has some bugs
> about setQueryTimeout fixed by Heikki(*).
> (*) http://www.postgresql.org/message-id/52A0D28A.7040902@vmware.com
>
> So I need the PostgreSQL Driver 9.3-1101 have good performance
> like 9.2-1004 as soon as possible.
>
> Could you check it please?
> If I'm missing something, please tell me it!
>
> regards,
> ------------------------
> Tomonari Katsumata
>
>
> (2014/03/06 18:13), Tomonari Katsumata wrote:
> > 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
> > >>>
> > >>
> > >>
> > >
> >
> >
> >
>
>
>

In response to

Responses

Browse pgsql-jdbc by date

  From Date Subject
Next Message Tomonari Katsumata 2014-04-15 08:20:08 Re: About binaryTransfer.
Previous Message Dave Cramer 2014-04-14 17:07:52 Re: properties and url