Re: Plan caching and serialization for reuse across executions

On 18/8/2025 16:18, Tom Lane wrote:
> Andrei Lepikhov <lepihov(at)gmail(dot)com> writes:
>> I wouldn't recommend this obsolete version of the extension. Since the
>> QueryId was introduced, we have redesigned it extensively, with the
>> basic idea that QueryId serves as a 'query plan class' and that matching
>> parse trees provide a proof of matching incoming queries with their
>> corresponding [parameterised] plans.
>
> That's fairly scary, considering all the work that's been done to
> intentionally fuzz different queries together to make them look
> like "the same query" to pg_stat_statements. While that's fine
> for pg_stat_statements, it makes it really questionable to assume
> that QueryId is a sufficient proof of semantic equivalence.
>
> (I recall having objected to the whole concept of moving queryjumble.c
> into core on the grounds that it could not serve multiple masters.
> I think this proves my point...)
I recall that this feature is on the "we never want it" list. It was
designed using a core patch and includes a custom, more selective query
ID. That's why I recently tried to discuss the extensibility of query
IDs in several threads.
As mentioned earlier, the query ID is utilised to narrow the search
space, resulting in no more than two to three additional costly checks,
according to my research. This allows the feature to be both practical
and efficient. The accuracy of the proof is determined by a parse tree
match, along with a few additional checks on the existence of indexes
and stuff like that.
I have never considered contributing any part of this to the core, just
as the pg_hint_plan does.

--
regards, Andrei Lepikhov