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 08:29:47 |
Message-ID: | 20020430102947.A25021@zf.jcu.cz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Apr 29, 2002 at 03:43:30PM -0400, Tom Lane wrote:
> I'm planning to add a mechanism to backend/utils/cache/inval.c that will
> allow additional modules to register to get notification of syscache and
> relcache invalidation events. Right now, only the syscache and relcache
> get told about it --- but there's no reason we couldn't call additional
> routines here.
>
> The immediate thing I want this for is so that the namespace.c routines
> can safely use a cached list of OIDs for accessible namespaces. Without
> this cache, we'll have to repeatedly look up pg_namespace entries and
> check their USAGE privilege bits. That strikes me as a fairly expensive
> operation to have to do for each table, function, and operator name in
> every query, when in practice the results aren't going to be changing
> very often. I'd like to only do the lookups when search_path changes
> or we receive a notification of an update in pg_namespace.
>
> This mechanism would also allow us to solve the plpgsql-cached-plans
> problem that keeps coming up. If plpgsql registers a callback routine
> for relcache events, then it'll get a notification every time something
> happens to a relation schema. It could search its cached plans to see
> if there is any reference to that relation OID. If so, blow away the
IMHO is clean call a callback if a change is relavant for cached
plan -- it means if Oid is used in plan.
> cached plan. (Or at least prevent it from being used again. There'd
> be some possibility of this happening for a plan that's currently in
> use, I believe, so you'd probably need to avoid discarding the plan
> until the active call is done.)
>
> We'll have the same problem with the PREPAREd-plan feature that Neil is
> working on, so it seems like time to do this. Comments?
Wanted! It's very good idea.
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 );
and now I can do:
mycallback(reg, mycallbackdata)
{
remove_plan_from_my_cache( (MyKey *) mycallbackdata );
UnregisterOidsCallback(reg);
}
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
From | Date | Subject | |
---|---|---|---|
Next Message | Hannu Krosing | 2002-04-30 10:37:24 | Re: Temp tables are curious creatures.... |
Previous Message | Christopher Kings-Lynne | 2002-04-30 06:59:27 | Re: [RFC] Set Returning Functions |