Re: track generic and custom plans in pg_stat_statements

On Thu, Jul 24, 2025 at 01:14:47PM -0500, Sami Imseih wrote:
>> Sami Imseih <samimseih(at)gmail(dot)com> writes:
>>>> That is not to say that I think 719dcf3c4 was a good idea: it looks
>>>> rather useless from here. It seems to me that the right place to
>>>> accumulate these sorts of stats is in CachedPlanSources, and I don't
>>>> see how this helps. What likely *would* help is some hooks in
>>>> plancache.c for pg_stat_statements to connect into so it can count
>>
>>> One possible hook for accumulating custom and generic plans per
>>> queryId would be inside GetCachedPlan. However, this would require
>>> calling pgss_store an extra time, in addition to ExecutorEnd, every time
>>> GetCachedPlan is executed, which could introduce non-negligible
>>> overhead.

I would suspect more contention on the PGSS locks in the prepared
statement and/or extended query protocol case if we were to do that.
With the amount of information we want to track in PGSS, which is that
we want to know from where a plan is coming from (generic cache,
custom cache or something else), FWIW I'm still OK with this
information added in PlannedStmt itself to be able to link back to the
state retrieved at the end of the executor because it's also
cost-free.

I'm also OK to be proved wrong based on arguments that could justify
the addition of an extra hook, but I don't really see the use-cases
that could justify such additions yet. Perhaps CachedPlanType is
misnamed, though, would it be more suited to name that as a sort of
"origin" or "source" field concept? We want to know which which
source we have retrieved a plan that a PlannedStmt refers to.
--
Michael