yes this can be usefull, under the condition of differentiating all the counters for a queryid using a generic plan and the one using a custom one.
For me one way to do that is adding a generic_plan column to pg_stat_statements key, someting like: - userid, - dbid, - queryid, - generic_plan
Thanks for your kind advice!
I don't know if generic/custom plan types are available during planning and/or execution hooks ...
Yeah, that's what I'm concerned about.
As far as I can see, there are no variables tracking executed plan types so we may need to add variables in CachedPlanSource or somewhere.
CachedPlanSource.num_custom_plans looked like what is needed, but it is the number of PLANNING so it also increments when the planner calculates both plans and decides to take generic plan.
To track executed plan types, I think execution layer hooks are appropriate. These hooks, however, take QueryDesc as a param and it does not include cached plan information. Portal includes CachedPlanSource but there seem no hooks to take Portal.
So I'm wondering it's necessary to add a hook to get Portal or CachedPlanSource. Are these too much change for getting plan types?