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
Karel Zak <zakkr(at)zf(dot)jcu(dot)cz>
C, PostgreSQL, PHP, WWW, http://docs.linux.cz, http://mape.jcu.cz
In response to
pgsql-hackers by date
|Next:||From: Tom Lane||Date: 2002-04-30 14:39:38|
|Subject: Re: Syscache/relcache invalidation event callbacks |
|Previous:||From: Tom Lane||Date: 2002-04-30 13:58:43|
|Subject: Re: [RFC] Set Returning Functions |