Re: track generic and custom plans in pg_stat_statements

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