Re: track generic and custom plans in pg_stat_statements

On 24/7/2025 09:03, Michael Paquier wrote:
> On Wed, Jul 23, 2025 at 12:15:06PM +0900, Michael Paquier wrote:
>> A small thing that would be cleaner is to split the patch into two
>> parts: one for the in-core backend addition and a second for PGSS.
>> Code paths are different, so it's simple to do.
>
> I have been looking at the backend part of the change to add the
> cached plan type to PlannedStmt, and found the concept clean.  I have
> moved the definition of the new enum to plannodes.h, tweaked a couple
> of comments and the result seemed OK, so applied this part.
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?

Currently, we are unable to track specific queries and analyse how planning
decisions affect their execution. IMO, this is a missed opportunity, as even
an extension-based feedback system could pave the way for developments
in self-tuning DBMS. Plan cache entries seem to be the most suitable target
for this purpose, as they usually refer to a long-lived statement and already
contain some valuable data.

--
regards, Andrei Lepikhov