Re: Syscache/relcache invalidation event callbacks
| От | Tom Lane |
|---|---|
| Тема | Re: Syscache/relcache invalidation event callbacks |
| Дата | |
| Msg-id | 19687.1020174209@sss.pgh.pa.us обсуждение исходный текст |
| Ответ на | Re: Syscache/relcache invalidation event callbacks (Karel Zak <zakkr@zf.jcu.cz>) |
| Ответы |
Re: Syscache/relcache invalidation event callbacks
|
| Список | pgsql-hackers |
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
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
В списке pgsql-hackers по дате отправления: