Re: track generic and custom plans in pg_stat_statements

On Mon, Jun 30, 2025 at 02:45:49PM +0300, Sami Imseih wrote:
> Only changes to the tests due to the revert of nested query
> tracking in f85f6ab051b

@@ -35,6 +36,7 @@ typedef struct QueryDesc
 	/* These fields are provided by CreateQueryDesc */
 	CmdType		operation;		/* CMD_SELECT, CMD_UPDATE, etc. */
 	PlannedStmt *plannedstmt;	/* planner's output (could be utility, too) */
+	CachedPlan *cplan;			/* CachedPlan that supplies the plannedstmt */

Ugh.  This is plugging into an executor-related structure a completely
different layer, so that looks like an invasive layer violation to
me..  This is passed through ProcessQuery() from a Portal, changing
while on it ExplainOnePlan.  If we want to get access from a cached
plan, wouldn't it be simpler to check if we have an active portal in
one of the executor hooks of PGSS and retrieve the status of the plan
from it?  Okay, that's perhaps a bit hack-ish, but it is less invasive
and it removes the dependency to the plan cache facilities from
QueryDesc. 

Note: the size of the change in pg_stat_statements--1.12--1.13.sql
points that we should seriously consider splitting these attributes
into multiple sub-functions.  That would make future upgrades simpler,
and the main function simpler even if we are a bit more lossy when
doing scans of PGSS entries across multiple functions with joins based
on the query ID, database ID and toplevel at least, because that's
what I guess we would use as common point for all the sub-functions
when joining them.
--
Michael