Re: track generic and custom plans in pg_stat_statements
Sami Imseih <samimseih@gmail.com>
From: Sami Imseih <samimseih@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Michael Paquier <michael@paquier.xyz>,
Andrei Lepikhov <lepihov@gmail.com>, 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-25T19:34:07Z
Lists: pgsql-hackers
> Sami Imseih <samimseih@gmail.com> writes: > >> Perhaps CachedPlanType is > >> misnamed, though, would it be more suited to name that as a sort of > >> "origin" or "source" field concept? We want to know which which > >> source we have retrieved a plan that a PlannedStmt refers to. > > > Hmm, I’m not sure I see this as an improvement. In my opinion, > > CachedPlanType is a clear name that describes its purpose. > > I think Michael's got a point. As of HEAD there are seven different > places that are setting this to PLAN_CACHE_NONE; who's to say that > pg_stat_statements or some other extension might not wish to > distinguish some of those sources? At the very least, user-submitted > versus internally-generated queries might be an interesting > distinction. I don't have a concrete proposal for a different > categorization than what we've got, but it seems worth considering > while we still have the flexibility to change it easily. Sure, I get it now, I think. An example is the cached plan from a sql in a utility statement of a prepared statement, as an example. right? I can see that being useful, If I understood that correctly. -- 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