Re: Is it safe to cache data by GiST consistent function - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Is it safe to cache data by GiST consistent function
Date
Msg-id 140857.1712163733@sss.pgh.pa.us
Whole thread Raw
In response to Re: Is it safe to cache data by GiST consistent function  (Michał Kłeczek <michal@kleczek.org>)
Responses Re: Is it safe to cache data by GiST consistent function
List pgsql-hackers
=?utf-8?Q?Micha=C5=82_K=C5=82eczek?= <michal@kleczek.org> writes:
> On 3 Apr 2024, at 16:27, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> AFAIK it works.  I don't see any of the in-core ones doing so,
>> but at least range_gist_consistent and multirange_gist_consistent
>> are missing a bet by repeating their cache search every time.

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

            regards, tom lane



pgsql-hackers by date:

Previous
From: Bharath Rupireddy
Date:
Subject: Re: LogwrtResult contended spinlock
Next
From: Melanie Plageman
Date:
Subject: Re: Streaming read-ready sequential scan code