"Simon Riggs" <[EMAIL PROTECTED]> writes: > On Tue, 2007-03-06 at 12:22 -0500, Tom Lane wrote: >> A. Just accept the extra overhead, thereby preserving the current >> behavior of unnamed statements, and gaining the benefit that plan >> invalidation will work correctly in the few cases where an unnamed >> statement's plan lasts long enough to need replanning.
> With connection pooling, multiple sessions will execute each statement. > If we check the cache each time this does seem more expensive for each > individual session, but we should gain synergy from other similar > sessions. It seems fairly unlikely to me that client code would try to share an unnamed statement across multiple application threads; the entire point is that it's for one-off queries. Or did you miss the point that the plan cache is local per-backend? > ISTM there will be some cases where the current behaviour will not be > maintained if we implement A exactly. One thing I've not seen mentioned > is the effect of constants on various plans. There is none. regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match