From: Tom Lane <tgl@sss.pgh.pa.us>
To: =?utf-8?Q?Micha=C5=82_K=C5=82eczek?= <michal@kleczek.org>
cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Subject: Re: Is it safe to cache data by GiST consistent function
In-reply-to: <43760F57-BBFF-4BBD-B272-EC7BD5F5A8AE@kleczek.org>
References: <3F12E994-B9E7-4308-9E18-5F01E28F55AC@kleczek.org> <2048131.1712154421@sss.pgh.pa.us> <43760F57-BBFF-4BBD-B272-EC7BD5F5A8AE@kleczek.org>
Comments: In-reply-to =?utf-8?Q?Micha=C5=82_K=C5=82eczek?= <michal@kleczek.org>
	message dated "Wed, 03 Apr 2024 18:47:03 +0200"
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-ID: <140856.1712163733.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Wed, 03 Apr 2024 13:02:13 -0400
Message-ID: <140857.1712163733@sss.pgh.pa.us>
Archived-At: <https://www.postgresql.org/message-id/140857.1712163733%40sss.pgh.pa.us>
Precedence: bulk

=3D?utf-8?Q?Micha=3DC5=3D82_K=3DC5=3D82eczek?=3D <michal@kleczek.org> writ=
es:
> 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 cac=
hed values are recalculated:

> 	cache =3D (gtrgm_consistent_cache *) fcinfo->flinfo->fn_extra;
> 	if (cache =3D=3D NULL ||
> 		cache->strategy !=3D strategy ||
> 		VARSIZE(cache->query) !=3D querysize ||
> 		memcmp((char *) cache->query, (char *) query, querysize) !=3D 0)

> What I don=E2=80=99t understand is if it is necessary or it is enough to=
 check fn_extra=3D=3DNULL.

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