On Thu, Aug 31, 2006 at 01:56:29PM +0200, Peter Eisentraut wrote:
> With time, it becomes ever clearer to me that prepared SQL statements are 
> just 
> a really bad idea.  On some days, it seems like half the performance problems 
> in PostgreSQL-using systems are because a bad plan was cached somewhere.  I'd 
> say, in the majority of cases the time you save parsing and planning is 
> irrelevant compared to the possibly disastrous effects of wrong or suboptimal 
> plans.  I wonder if other people have similar experiences.

Yeah, it seems to me that many of the benefits of not planning are
overrun by the effects of bad plans.

> - Redefine "prepared" to mean "parsed" rather than "parsed and planned".

I think this is the best. Some way to specify that you don't want
planning to take place immediately would be good.

One question though: there is a function PQexecParams(). Does this
suffer from the same problem? I imagine most interfaces like
out-of-band parameters (no escaping issues), why do they not use this?

Have a nice day,
Martijn van Oosterhout   <kleptog@svana.org>   http://svana.org/kleptog/
> From each according to his ability. To each according to his ability to 
> litigate.

Attachment: signature.asc
Description: Digital signature

Reply via email to