Re: track generic and custom plans in pg_stat_statements

On 24/7/2025 17:05, Tom Lane wrote:
> Andrei Lepikhov <lepihov(at)gmail(dot)com> writes:
>> I see you have chosen a variant with a new enum instead of a pointer to
>> a plan cache entry. I wonder if you could write the arguments
>> supporting this choice?
>
> Pointing to a plan cache entry would often mean that the data
> structure as a whole is circular (since a plan cache entry
> will have a pointer to a plan). That would in particular
> make it unsafe for the plan to protect its pointer by incrementing
> the cache entry's refcount --- the assemblage could never go away.
> So I concur with Michael that what you propose is a bad idea.
I was expecting more substantial arguments. The PostgreSQL code does not
restrict back-linking to the source in principle - see
IndexClause::rinfo for an example. I'm not sure what the problem is with
refcount - in extensions, we currently have access to the plan cache
entry for prepared statements.

In this particular case, I suggested storing a pointer to the
CachedPlanSource instead of the CachedPlan. For a custom plan, we won't
encounter any circular references, and for a generic plan, the reference
will be indirect.

Of course, read and write operations should be disabled for such a
pointer, and the copy operation should only duplicate the pointer itself.

--
regards, Andrei Lepikhov