On Tue, 30 Dec 2008, Tom Lane wrote:
> Scott Carey <scott@richrelevance.com> writes:
>> I have also had a case where one query would take a couple hundred ms to parse, but was fairly fast to plan and
execute(1/3 the parse cost) -- yet another case where a prepared statement that re-plans each execution would be
helpful. At least you can prevent SQL injection and cut the parse cost. Its not all about the cost of planning the
query.
>
> The point of a prepared statement IMHO is to do the planning only once.
> There's necessarily a tradeoff between that and having a plan that's
> perfectly adapted to specific parameter values.
actually, it does two things
1. planning only once
2. parsing only once.
I suspect that when this was initially setup the expectation was that the
planning was the expensive thing that should be avoided.
in this case a post earlier in the thread identified parsing of the query
as being the expensive thing (planning + execution was 1/3 the cost of the
parsing)
since there is not a pre-parsed interface for queries, it may make sense
to setup a way to have the query pre-parsed, but not pre-planned for cases
like this.
David Lang