Re: track generic and custom plans in pg_stat_statements
Michael Paquier <michael@paquier.xyz>
From: Michael Paquier <michael@paquier.xyz>
To: Sami Imseih <samimseih@gmail.com>
Cc: Andrei Lepikhov <lepihov@gmail.com>, Tom Lane <tgl@sss.pgh.pa.us>, 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-31T00:09:14Z
Lists: pgsql-hackers
On Wed, Jul 30, 2025 at 03:09:08PM -0500, Sami Imseih wrote: >> In practice, with this knowledge, we can access the CachedPlanSource of >> the corresponding PREPARED statement via an extension and override the >> decision made in 'auto' mode. Unfortunately, we cannot obtain a pointer >> to plan cache entries for plans prepared by the extended protocol, but >> this may be possible in the future. >> >> So, I meant that the source of the plan is one important characteristic, >> and the type (custom or generic) is another, independent characteristic It seems to me that we're going to need a bit more than a design concept here, explaining how this can be useful for core to provide this knowledge to extensions. A lot of concepts can be defined as "useful", but it's hard to evaluate what you'd want here and how much it can be useful in terms of manipulations of the cached plans depending on what you may aim for. It's also unclear up to which extent the current state of the code would be able to help in the concepts you're describing. Anyway, I am not inclined to have pointer references in structures pointing to other parts of the system, just because these can be "useful". -- Michael
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