From: | Michał Kłeczek <michal(at)kleczek(dot)org> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Is it safe to cache data by GiST consistent function |
Date: | 2024-04-04 03:20:59 |
Message-ID: | 52A53C2B-6A75-4BFE-A344-ED9298874043@kleczek.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> On 3 Apr 2024, at 19:02, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> =?utf-8?Q?Micha=C5=82_K=C5=82eczek?= <michal(at)kleczek(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Thomas Munro | 2024-04-04 03:22:17 | Re: Extension Enhancement: Buffer Invalidation in pg_buffercache |
Previous Message | David Rowley | 2024-04-04 03:09:03 | Re: On disable_cost |