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
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 |