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

Reply via email to