Harald Fuchs wrote: > In article <[EMAIL PROTECTED]>, > Tom Lane <[EMAIL PROTECTED]> writes: > > > One possible approach is to do the invalidation on a sufficiently coarse > > grain that we don't care. For example, I would be inclined to make any > > change in a table's schema invalidate all plans that use that table at > > all; that would then subsume the constraint problem for instance. This > > doesn't solve the inlined function problem however. > > How about using an even coarser grain? Whenever something in the > database in question changes, blindly throw away all cached plans for > this DB.
We could, but the creation of a single temp table would invalidate all caches, and temp table creation might be pretty frequent. One idea would be to record if the function uses non-temp tables, temp tables, or both, and invalidate based on the type of table being invalidated, rather than the table name itself. I can imagine this hurting temp table caching, but at least functions using regular tables would not be affected, and functions using temp tables would work reliably. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073 ---------------------------(end of broadcast)--------------------------- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly