Re: track generic and custom plans in pg_stat_statements

Andrei Lepikhov <lepihov@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
replanning events.

			regards, tom lane