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
