[prev in list] [next in list] [prev in thread] [next in thread] 

List:       postgresql-general
Subject:    Re: [HACKERS] Syscache/relcache invalidation event callbacks
From:       Karel Zak <zakkr () zf ! jcu ! cz>
Date:       2002-04-30 15:22:10
[Download RAW message or body]

On Tue, Apr 30, 2002 at 10:39:38AM -0400, Tom Lane wrote:
> Karel Zak <zakkr@zf.jcu.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@zf.jcu.cz>
 http://home.zf.jcu.cz/~zakkr/
 
 C, PostgreSQL, PHP, WWW, http://docs.linux.cz, http://mape.jcu.cz

---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

http://archives.postgresql.org
[prev in list] [next in list] [prev in thread] [next in thread]