Re: track generic and custom plans in pg_stat_statements
Michael Paquier <michael@paquier.xyz>
From: Michael Paquier <michael@paquier.xyz>
To: Andrei Lepikhov <lepihov@gmail.com>
Cc: Sami Imseih <samimseih@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-28T06:46:39Z
Lists: pgsql-hackers
On Mon, Jul 28, 2025 at 08:41:29AM +0200, Andrei Lepikhov wrote: > It looks good, but doesn't it seem too narrow? For the use case of the thread which is to count the number of custom vs generic plans, it would be good enough. > This minor change allows an extension to track a specific query from > the parse tree up to the end of execution and carry as much data as > needed. The extension (pg_stat_statements as well) may add all the > necessary data in the parse hook, planner hook, or any of the > execution hooks. With a trivial naming convention, Extensible nodes of > different extensions will not interfere. > To identify the cached plan, the GetCachedPlan hook may be introduced. Without knowing the actual use cases where these additions can be useful, introducing this extra amount of infrastructure may not be justified. Just my 2c and my impressions after studying the whole thread. -- 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