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
