Thread

Re: Plan caching and serialization for reuse across executions

Julien Rouhaud <rjuju123@gmail.com> — 2025-08-19T05:15:37Z

Hi,

On Mon, Aug 18, 2025 at 10:18:34AM -0400, Tom Lane wrote:
> Andrei Lepikhov <lepihov@gmail.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.