From: | Oliver Jowett <oliver(at)opencloud(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | James Robinson <jlrobins(at)socialserve(dot)com>, pgsql-jdbc(at)postgresql(dot)org |
Subject: | Re: Under what circumstances does PreparedStatement use stored |
Date: | 2004-04-13 21:39:46 |
Message-ID: | 407C5E22.50809@opencloud.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-jdbc |
Tom Lane wrote:
> James Robinson <jlrobins(at)socialserve(dot)com> writes:
>
>>... I suppose this all assumes that the lookup + maintenance of such a
>>datastructure would ultimately cost less than re-planning all queries
>>all the time.
>
>
> I think that is a safe bet to be true, as long as you get *some* mileage
> out of the plan cache. If the application issues a bunch of
> no-two-alike queries then it's a loss of course. But doesn't the JDBC
> API distinguish prepared statements from unprepared ones? ISTM it is
> the app programmer's responsibility to prepare just those statements
> he's likely to use more than once. I don't think the driver need
> second-guess this choice.
The problem is that JDBC's PreparedStatement provides two things:
repeated execution of the same query with different parameters, and
portable parameterization of queries. So it's likely that many one-shot
or infrequently executed queries will still use a PreparedStatement.
This is why a threshold on PreparedStatement reuse before using
PREPARE/EXECUTE seemed like a good idea -- we should be able to avoid
PREPARE-ing the one-shot queries, at a minimum.
-O
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Nonemacher | 2004-04-13 22:09:41 | Re: Under what circumstances does PreparedStatement use stored |
Previous Message | Oliver Jowett | 2004-04-13 21:18:12 | Re: Under what circumstances does PreparedStatement use stored |