Re: track generic and custom plans in pg_stat_statements
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Sami Imseih <samimseih@gmail.com>
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-25T16:51:12Z
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. regards, tom lane
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