Re: binary patch problems

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Maciek Sakrejda <msakrejda(at)truviso(dot)com>
Cc: Radosław Smogura <rsmogura(at)softperience(dot)eu>, pgsql-jdbc(at)postgresql(dot)org
Subject: Re: binary patch problems
Date: 2011-09-20 00:39:31
Message-ID: 25673.1316479171@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-jdbc

Maciek Sakrejda <msakrejda(at)truviso(dot)com> writes:
> I think what Tom is saying is that you'll be able to set
> prepareThreshold to 1 in the driver (always use named server-side
> prepared statements) and the server will automagically do the right
> thing. Right now, the big problem is that only unnamed prepared
> statements include the "feature" of being able to consider parameters
> in the query plan (since unnamed statements are not reused, there's no
> sense in planning them before you have parameters).

Right. We've rejiggered the backend so that planning is delayed until
parameter values are available in all cases. (If the code finds that
the plans it's getting with the parameters aren't materially better than
a generic plan would be, it'll eventually go back to using generic
plans. But hopefully you will never need to club it over the head to
avoid doing that.)

Anyway, this isn't going to hit the street for another year, so there's
no reason to worry about it too much right now. I'm just saying you
shouldn't invest a lot of work in related areas without being aware that
that change is coming.

regards, tom lane

In response to

Responses

Browse pgsql-jdbc by date

  From Date Subject
Next Message Craig Ringer 2011-09-20 05:00:53 Re: binary patch problems
Previous Message Kevin Grittner 2011-09-19 20:34:19 Re: behavior at the end of a transaction