Re: track generic and custom plans in pg_stat_statements

> Andrei Lepikhov <lepihov(at)gmail(dot)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