From: | Karel Zak <zakkr(at)zf(dot)jcu(dot)cz> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Syscache/relcache invalidation event callbacks |
Date: | 2002-04-30 15:22:10 |
Message-ID: | 20020430172210.H25021@zf.jcu.cz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Apr 30, 2002 at 10:39:38AM -0400, Tom Lane wrote:
> Karel Zak <zakkr(at)zf(dot)jcu(dot)cz> writes:
> > There must be possible define some callback specific data too, the
> > callback maybe will search query in some own specific cache and it
> > require some key.
>
> Yeah, I have it set up similarly to on_proc_exit callbacks: when you
> register the callback function you can also provide a Datum (typically
> a pointer). But I'm not sure that there's any real value in this.
> AFAICS, such callbacks are always going to be interested in looking
> through a cache data structure of some kind, and so there will always
> be global variables pointing to what they need to get to. (I'm
> envisioning *one* callback function handling a whole cache, not a
> callback for each entry!)
I understand.
> >> BTW, the inval callback had better just mark the plans invalid, not
> >> try to rebuild them right away. I don't think it's safe to try to
>
> > Hmm, it can depend on action, I can imagine:
>
> > DROP TABLE tab;
>
> > ERROR: mycallback(): can't rebuild the query used in PL/SQL function
> > 'xyz'. Please drop this function first.
>
> > ...table drop failed.
>
> Nope, that is NOT okay.
It was dream.
> (If we do want to prevent a drop in cases like this, it has to be done
> via the kind of dependency mechanism that Rod is working on.)
It's good that someone works on dreams:-)
> > There can be one query cache and one cached planns checking only, for RI,
> > SPI, PL/SQL, PREPARE/EXECUTE. Or not?
>
> Hmm. Seems like it might be a good idea, but I'm not certain that all
> of these have exactly the same requirements. If they can all share one
> cache that'd definitely be a win.
All they needs save query planns -- IMHO it's enough. It's always
couple "plan-identificator" + "plan-tree".
There is not problem create branchs of the cache, separate for SPI,
PL/SQL ..etc. But the _routines_ and API will _same_.
branch = qCache_CreateBranch("PL/SQL");
qCache_AddPlan(branch, plan, hashkey);
Karel
--
Karel Zak <zakkr(at)zf(dot)jcu(dot)cz>
http://home.zf.jcu.cz/~zakkr/
C, PostgreSQL, PHP, WWW, http://docs.linux.cz, http://mape.jcu.cz
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Sullivan | 2002-04-30 15:55:53 | Re: [HACKERS] Re : Solaris Performance - Profiling (Solved) |
Previous Message | Tom Lane | 2002-04-30 14:39:38 | Re: Syscache/relcache invalidation event callbacks |