Re: track generic and custom plans in pg_stat_statements

On 17/7/2025 20:19, Sami Imseih wrote:
> Thanks for the clarification. I see what you're getting at now.
Thanks for reading this!
>
> You're suggesting adding CachedPlanSource to QueryDesc instead of
> CachedPlan. This would allow extensions to access the statistics and cost
> information from the CachedPlanSource, which would help tools like
> pg_stat_statements track planning data, as we are trying to do with this
> patch. It could also support other use cases, such as allowing extensions to
> modify the costs in order to force a generic or custom plan. I had not
> considered that second use case, but if there is a good case for it, I am not
> opposed.
Hmm, I don't propose modifying costs. The focus is on resetting the plan
cache decision that PostgreSQL has made in automatic mode. During the
DBMS operation, various factors may cause a generic plan to be
suboptimal or make it more desirable as well. Discussions from 2010 to
2013 indicate that the community recognised the problem and discovered
an approach based on execution time and real efforts rather than a
cost-based method. While I doubt it could be ideal as a core solution,
an extension may potentially do it for the sake of TPS maximisation.
What we need is a way to access the plan cache entry.
>
> Adding CachedPlanSource to QueryDesc seems doable. However, Michael
> previously objected to adding CachedPlan to QueryDesc. Is there any
> similar hesitation about including CachedPlanSource?
I agree that we should investigate further to find the most optimal
solution. Personally, I'm open to including an internal reference to a
plan cache entry within the QueryDesc, as long as the plan has its roots
there.

> Andrei, do we actually need access to CachedPlanSource::cplan? For
> tracking the plan cache mode in pg_stat_statements, it be sufficient
> to add a new boolean field such as is_last_plan_generic to
> CachedPlanSource. Do you have another use case you have in mind
> that would require a cplan field that references either the generic or
> custom plan?
I'm not entirely sure. I followed your idea of referencing the entire
list of planned statements during the execution of a single statement.
The is_last_plan_generic field may be sufficient at first glance.

--
regards, Andrei Lepikhov