> On 3 Apr 2024, at 19:02, Tom Lane <t...@sss.pgh.pa.us> wrote: > > =?utf-8?Q?Micha=C5=82_K=C5=82eczek?= <mic...@kleczek.org> writes: > >> pg_trgm consistent caches tigrams but it has some logic to make sure cached >> values are recalculated: > >> cache = (gtrgm_consistent_cache *) fcinfo->flinfo->fn_extra; >> if (cache == NULL || >> cache->strategy != strategy || >> VARSIZE(cache->query) != querysize || >> memcmp((char *) cache->query, (char *) query, querysize) != 0) > >> What I don’t understand is if it is necessary or it is enough to check >> fn_extra==NULL. > > Ah, I didn't think to search contrib. Yes, you need to validate the > cache entry. In this example, a rescan could insert a new query > value. In general, an opclass support function could get called using > a pretty long-lived FunctionCallInfo (e.g. one in the index's relcache > entry), so it's unwise to assume that cached data is relevant to the > current call without checking.
This actually sounds scary - looks like there is no way to perform cache clean-up after rescan then? Do you think it might be useful to introduce a way for per-rescan caching (ie. setting up a dedicated memory context in gistrescan and passing it to support functions)? — Michal
