Re: Poor plan choice in prepared statement

Tom Lane escribió:
> 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.

I think it has been shown enough times that the performance drop caused
by a worse plan can be orders of magnitudes worse than what's gained by
producing the plan only once. It does not seem a bad idea to provide a
way to carry out only the parse phase, and postpone planning until the
parameters have been received.

--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.