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>, 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-21T23:07:42Z
Lists: pgsql-hackers
On Mon, Jul 21, 2025 at 04:47:31PM -0500, Sami Imseih wrote: > 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. Yes, I think that this is a much better idea to isolate the whole concept and let pgss grab these values. We have lived with such additions for monitoring in EState a few times already, see for example de3a2ea3b264 and 1d477a907e63 that are tainted with my fingerprints. -- 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