> > Ugh. This is plugging into an executor-related structure a completely > > different layer, so that looks like an invasive layer violation to > > me.. This is passed through ProcessQuery() from a Portal, changing > > while on it ExplainOnePlan. If we want to get access from a cached > > plan, wouldn't it be simpler to check if we have an active portal in > > one of the executor hooks of PGSS and retrieve the status of the plan > > from it? Okay, that's perhaps a bit hack-ish, but it is less invasive > > and it removes the dependency to the plan cache facilities from > > QueryDesc. > > I found that ActivePortal is to always "active" in ExecutorEnd for all > cases. > Also, ActivePortal->cplan may not always be available at ExecutorStart. > > I think we can rely on ActivePortal if we add a new field to portal which > tracks the cached plan status; i.e. we set ActivePortal->cache_plan_status > inside GetCachedPlan. Then in ExecutorStart, we read back this value and > store it in a new field in QueryDesc->estate. This will make the value > available to ExecutorEnd. I really don't want us making an extra pgss_store > call in ExecutorStart since it will add significant overhead. > > What do you think about adding these couple of fields? > > -- > Sami
But I also have doubts about calling ActivePortal Inside GetCachedPlan. It should only be used in the Executor So, I’m not sure ActivePortal could be very helpful here they way I describe it above. -- Sami
