Re: binary patch problems - Mailing list pgsql-jdbc

From Tom Lane
Subject Re: binary patch problems
Date
Msg-id 16752.1316443632@sss.pgh.pa.us
Whole thread Raw
In response to Re: binary patch problems  (Mikko Tiihonen <mikko.tiihonen@nitorcreations.com>)
Responses Re: binary patch problems  (Radosław Smogura <rsmogura@softperience.eu>)
List pgsql-jdbc
Mikko Tiihonen <mikko.tiihonen@nitorcreations.com> writes:
> On 09/19/2011 01:11 PM, Bodor Andras wrote:
>> Why don't you set prepareThreshold to 0 for your test cases?
>> In this case parameter passing starts immediately for the
>> prepared statement, and ForceBinaryTransfers can be dropped.

> AbstractJdbc2Statement:
>      public boolean isUseServerPrepare() {
>          return (preparedQuery != null && m_prepareThreshold != 0 && m_useCount + 1 >= m_prepareThreshold);
>      }

> If I read the above correctly then prepareThreshold of 0 disables prepared statements.

But "1" would do what you want, no?

FWIW, I'm hoping that this entire business of delaying the server-side
prepare will be obsolete as of 9.2.  There is already code committed in
HEAD that allows "prepared" statements to be re-planned for each new set
of parameter values, with a somewhat-informed choice of whether and when
to switch over to the traditional generic-plan approach.  It needs
tweaking for performance still, no doubt, but there is not going to be a
reason for the driver to do this anymore.

Obviously that's not much use for solving your immediate problem, but it
might lead you to conclude that putting a large amount of effort into
improving this mechanism would be a dead end.

            regards, tom lane

pgsql-jdbc by date:

Previous
From: Mikko Tiihonen
Date:
Subject: Re: binary patch problems
Next
From: Bodor Andras
Date:
Subject: Re: binary patch problems