> Andrei Lepikhov <lepi...@gmail.com> writes: > > I see you have chosen a variant with a new enum instead of a pointer to > > a plan cache entry. I wonder if you could write the arguments > > supporting this choice? > > Pointing to a plan cache entry would often mean that the data > structure as a whole is circular (since a plan cache entry > will have a pointer to a plan). That would in particular > make it unsafe for the plan to protect its pointer by incrementing > the cache entry's refcount --- the assemblage could never go away. > So I concur with Michael that what you propose is a bad idea. > > 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. -- Sami
