Re: track generic and custom plans in pg_stat_statements

On 17/7/2025 00:58, Sami Imseih wrote:
>> this for better tracking. By adding a CachedPlanSource::cplan link, we
>> can establish a connection to the entire PlanCache entry instead of only
>> CachedPlan within a queryDesc and, consequently, make it accessible from
>> the executor. This would give an access to statistics on costs and the
>> number of replannings.
> 
> This maybe out of scope for this patch, but can you elaborate on what you mean
> by "CachedPlanSource::cplan link" ?
You need to introduce a 'status' field, right? - to allow someone to 
identify the plan's type, which was previously somewhat complicated. 
However, it may be implemented in a slightly different way, by adding 
CachedPlanSource::cplan (meaning 'Current Plan') and a trivial 
convention: 'cplan' references the gplan field or it refers a custom 
plan. Instead of the CachedPlan, we may provide the executor with a link 
to more stable and informative CachedPlanSource entry. That's the main idea.
As I see it, CachedPlan doesn't make sense without plancache and a 
CachedPlanSource entry. So, it is at least a valid solution.

With that link, you can access various statistics: num_custom_plans, 
num_generic_plans, total_custom_cost, and generic_cost. It would also be 
possible to clear the *_cost fields and allow Postgres to make a new 
attempt at choosing the plan type - who knows, maybe the previous 
decision is already outdated?

My point is that we can address one of the common issues with generic 
plans in a more extensible way, enabling modules to access the 
CachedPlanSource data at the time they have access to the execution 
instrumentation.

It seems impractical to me to invent one more patch: since you've 
already modified the CreateQueryDesc interface and introduced a plan 
type identification logic, why do it twice?

-- 
regards, Andrei Lepikhov