Re: Is it safe to cache data by GiST consistent function

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Michał Kłeczek <michal(at)kleczek(dot)org>
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-03 17:02:13
Message-ID: 140857.1712163733@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

=?utf-8?Q?Micha=C5=82_K=C5=82eczek?= <michal(at)kleczek(dot)org> writes:
> On 3 Apr 2024, at 16:27, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Melanie Plageman 2024-04-03 17:02:57 Re: Streaming read-ready sequential scan code
Previous Message Bharath Rupireddy 2024-04-03 17:00:00 Re: LogwrtResult contended spinlock