Re: Plan caching and serialization for reuse across executions

Hi,

On Mon, Aug 18, 2025 at 10:18:34AM -0400, 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 don't think it really proves your point, the queryid is only a hash and
collisions are possible. So even if the core jumbling didn't fuzz different
queries together you would still need a secondary check to ensure correctness,
and IIUC Andrei said that they use the actual parsetree for that. I wrote a
prototype of extension to implement a shared plan cache some years ago and I
also did something similar. Even if the queryid is not (and cannot be) perfect
it's still highly useful in many situations.