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.
signature.asc
Description: Digital signature
