Re: [PERFORM] Query much slower when run from postgres function

Dave Cramer wrote:
>
>
> On Mon, Mar 9, 2009 at 1:16 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us
> <mailto:tgl(at)sss(dot)pgh(dot)pa(dot)us>> wrote:
>
> Guillaume Smet <guillaume(dot)smet(at)gmail(dot)com
> <mailto:guillaume(dot)smet(at)gmail(dot)com>> writes:
> > Unnamed prepared statements are planned after binding the values,
> > starting with 8.3, or more precisely starting with 8.3.2 as early 8.3
> > versions were partially broken on this behalf.
>
> No, 8.2 did it too (otherwise we wouldn't have considered 8.3.0 to be
> broken...). The thing I'm not too clear about is what "use of an
> unnamed statement" translates to for a JDBC user.
>
>
> Tom,
>
> The driver will use unnamed statements for all statements until it sees
> the same statement N times where N is 5 I believe, after that it uses a
> named statement.

Right, with the caveat that "the same statement" means "exactly the same
PreparedStatement object". If you happen to run the same (textual) query
via two different PreparedStatement objects, they're still considered
different queries for the purposes of this threshold.

You can also tune the threshold via the prepareThreshold parameter in
the driver URL, or use org.postgresql.PGStatement.setPrepareThreshold
(an extension interface implemented by the driver on its Statement
objects) on a per-statement basis.

prepareThreshold=0 is a special value that means "never use a named
statement".

The idea behind the threshold is that if a PreparedStatement object is
reused, that's a fairly good indication that the application wants to
run the same query many times with different parameters (since it's
going to the trouble of preserving the statement object for reuse). But
it's all tunable if needed.

Also see http://jdbc.postgresql.org/documentation/head/server-prepare.html

-O