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
Views: Raw Message | Whole Thread | Download mbox | Resend email
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

Browse pgsql-hackers by date

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