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
