From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | pgsql-jdbc(at)postgresql(dot)org |
Subject: | Re: binary patch problems |
Date: | 2011-09-19 14:47:12 |
Message-ID: | 16752.1316443632@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-jdbc |
Mikko Tiihonen <mikko(dot)tiihonen(at)nitorcreations(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Bodor Andras | 2011-09-19 15:15:51 | Re: binary patch problems |
Previous Message | Guillaume | 2011-09-19 14:39:38 | jdbc and automagic casting |