> 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.
