Re: track generic and custom plans in pg_stat_statements - Mailing list pgsql-hackers

From Tom Lane
Subject Re: track generic and custom plans in pg_stat_statements
Date
Msg-id 1647760.1753369510@sss.pgh.pa.us
Whole thread Raw
In response to Re: track generic and custom plans in pg_stat_statements  (Andrei Lepikhov <lepihov@gmail.com>)
Responses Re: track generic and custom plans in pg_stat_statements
Re: track generic and custom plans in pg_stat_statements
List pgsql-hackers
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



pgsql-hackers by date:

Previous
From: Laurenz Albe
Date:
Subject: Commitfest 2025-03 still has active patches
Next
From: Damien Clochard
Date:
Subject: Re: [PATCH] Generate random dates/times in a specified range