Re: track generic and custom plans in pg_stat_statements

> Sami Imseih <samimseih@gmail.com> writes:
> >> That is not to say that I think 719dcf3c4 was a good idea: it looks
> >> rather useless from here.  It seems to me that the right place to
> >> accumulate these sorts of stats is in CachedPlanSources, and I don't
> >> see how this helps.  What likely *would* help is some hooks in
> >> plancache.c for pg_stat_statements to connect into so it can count
>
> > One possible hook for accumulating custom and generic plans per
> > queryId would be inside GetCachedPlan. However, this would require
> > calling pgss_store an extra time, in addition to ExecutorEnd, every time
> > GetCachedPlan is executed, which could introduce non-negligible
> > overhead.
>
> Only if you insist that the way to handle this is to call pgss_store
> at that time.  I'd be inclined to think about having some transient
> process-local data structure that can remember the info until
> ExecutorEnd.  But the plan tree is not the right place, because of
> the circularity problem.

One option might be to use a local hash table, keyed the same way as the
shared pgss hash (excluding dbid), to handle cases where a backend has
more than one active cached plan. Then at ExecutorEnd, the local entry could
be looked up and passed to pgss_store. Not sure if this is worth the effort vs
what has been committed.

--
Sami