Re: track generic and custom plans in pg_stat_statements
Sami Imseih <samimseih@gmail.com>
From: Sami Imseih <samimseih@gmail.com>
To: Andrei Lepikhov <lepihov@gmail.com>
Cc: Greg Sabino Mullane <htamfids@gmail.com>,
pgsql-hackers <pgsql-hackers@postgresql.org>, Nikolay Samokhvalov <nik@postgres.ai>,
Ilia Evdokimov <ilya.evdokimov@tantorlabs.com>
Date: 2025-07-21T21:47:31Z
Lists: pgsql-hackers
Attachments
- v12-0001-Add-counters-for-generic-and-custom-plan-executi.patch (application/octet-stream) patch v12-0001
> > "plan cache mode" to be accessible in ExecutorEnd somehow. > I agree with this - adding references to CachedPlan into the QueryDesc > looks kludge. > The most boring aspect of pg_stat_statements for me is the multiple > statements case: a single incoming query (the only case in the cache of > a generic plan) may be rewritten as various statements with the same > query ID. So, the execution time of the initial statement should be the > sum of the executions of all rewritten parts. AFAICT, It does sum up the stats of rewritten statements of a single statement, since each one of those statements does call ExecutorEnd ( under the same queryId ). > If the multiple-statements case didn't exist for a cached statement, > Michael's idea with an active portal would be much better, and it would > make sense to add PlanCacheSource::cplan and replace Portal::CachedPlan > with Portal::PlanCacheSource reference. I don't like ActivePortal because cplan itself does not live by ExecutorEnd [0] and in some cases it's not available in ExecutorStart ( think of Explain/Explain Analyze), so you still need to add some handling for those cases, which I don't think we can ignore. Also, if we say we can forgo tracking the Explain/Explain Analyze case, we surely don't want to call pgss_store at ExecutorStart to set the plan cache mode stats and ExecutorEnd to set everything else for a particular execution. In short, we still need some fields to be added to QueryDesc to track the plan cache mode info. Last week I published a v11 that adds a field to QueryDesc, but as I thought about this more, how about we just add 2 bool fields in QueryDesc->estate ( es_cached_plan and es_is_generic_plan ), a field in CachedPlan ( is_generic_plan ) and after ExecutorStart, and if we have a cplan, we set the appropriate plan cache mode value. I think it's better to confine these new fields in Estate rather than at a higher level like QueryDesc. See v12. [0] https://www.postgresql.org/message-id/CAA5RZ0t4kmbBM%2BetEQVb1c8bMSWjKOY8zTEA43X2UhSu0A8dCA%40mail.gmail.com -- Sami
Commits
-
pg_stat_statements: Add counters for generic and custom plans
- 3357471cf9f5 19 (unreleased) landed
-
Rename CachedPlanType to PlannedStmtOrigin for PlannedStmt
- e125e360020a 19 (unreleased) landed
-
Introduce field tracking cached plan type in PlannedStmt
- 719dcf3c4226 19 (unreleased) landed