On Thu, August 31, 2006 18:56, 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.
Is there any kind of pattern at all to this problem? Anything recognizable? A few typical pitfalls? Without knowing much of the internals, I could imagine [waves hands in vague gestures] other options--something like recognizing major changes that upset the cost functions that went into generating a plan, and invalidating the plan based on those; or noting bad estimates somehow as they become apparent during execution, and annotating the plan with a "this assumption was a bad idea" marker so you'll do better next time. I guess you can't go far wrong if you re-define "prepared" to mean merely "pre-parsed," but it sounds like such a waste of opportunity... Jeroen ---------------------------(end of broadcast)--------------------------- TIP 2: Don't 'kill -9' the postmaster
