From: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
---|---|
To: | hf1122x(at)protecting(dot)net |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: invalidating cached plans |
Date: | 2005-03-15 01:06:46 |
Message-ID: | 200503150106.j2F16kI20022@candle.pha.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Harald Fuchs wrote:
> In article <6028(dot)1110785150(at)sss(dot)pgh(dot)pa(dot)us>,
> Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> 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(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
From | Date | Subject | |
---|---|---|---|
Next Message | Neil Conway | 2005-03-15 01:24:40 | Re: invalidating cached plans |
Previous Message | Harald Fuchs | 2005-03-15 00:00:46 | Re: invalidating cached plans |