Re: Poor plan choice in prepared statement

On Tue, 30 Dec 2008, Tom Lane wrote:

> Scott Carey <scott(at)richrelevance(dot)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