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