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.

regards, tom lane