> Sami Imseih <samims...@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
