Skip site navigation (1) Skip section navigation (2)

Re: Syscache/relcache invalidation event callbacks

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 14:26:55
Message-ID: 20020430162655.F25021@zf.jcu.cz (view raw or flat)
Thread:
Lists: pgsql-hackers
On Tue, Apr 30, 2002 at 09:43:29AM -0400, Tom Lane wrote:
> Karel Zak <zakkr(at)zf(dot)jcu(dot)cz> writes:
> >  I have a question, how I will know how changes are relevant for my 
> >  query plan? IMHO is needful some hight-level API, like
> 
> >     list = ExtractQueryPlanOids( plan );
> >     reg = RegisterOidsCallback( list, mycallback, mycallbackdata );
> 
> Yes, some kind of routine to extract all the referenced relation OIDs

 The relations or others things like operators, functions, etc. Right?

> in a plan tree would be a good idea.  I can provide that.  The inval
> callback just tells you the OID of the relation that got flushed; it's
> up to you to get from there to the plans you need to rebuild.  Perhaps
> a hash table would work well.

 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.
 
> 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.
  
 This is maybe not possible implement now, but it's ideal conception
 :-)
 
> do more database accesses while we're in the relcache invalidation
> path.  "Rebuild plan on next attempted use" seems like a better idea.

 Agree. It means store to cache query string too (I not sure if it's
 used in current qcache, but it's simple).

 There can be one query cache and one cached planns checking only, for RI, 
 SPI, PL/SQL, PREPARE/EXECUTE. Or not? I think implement 4x same things is 
 terrible.

        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

In response to

Responses

pgsql-hackers by date

Next:From: Tom LaneDate: 2002-04-30 14:39:38
Subject: Re: Syscache/relcache invalidation event callbacks
Previous:From: Tom LaneDate: 2002-04-30 13:58:43
Subject: Re: [RFC] Set Returning Functions

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group