Re: track generic and custom plans in pg_stat_statements

> Sami Imseih <samimseih(at)gmail(dot)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