On Tue, Apr 30, 2002 at 09:43:29AM -0400, Tom Lane wrote:
> Karel Zak <zakkr@zf.jcu.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, thecallback maybe will search query in some own specific
cacheand itrequire 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.
...tabledrop 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'sused 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
implement4x same things is terrible.
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