Re: Syscache/relcache invalidation event callbacks

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Karel Zak <zakkr(at)zf(dot)jcu(dot)cz>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Syscache/relcache invalidation event callbacks
Date: 2002-04-30 13:43:29
Message-ID: 19687.1020174209@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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
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.

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
do more database accesses while we're in the relcache invalidation
path. "Rebuild plan on next attempted use" seems like a better idea.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2002-04-30 13:58:43 Re: [RFC] Set Returning Functions
Previous Message Rod Taylor 2002-04-30 12:18:14 Re: Temp tables are curious creatures....