Re: track generic and custom plans in pg_stat_statements

Sami Imseih <samimseih@gmail.com>

From: Sami Imseih <samimseih@gmail.com>

To: Michael Paquier <michael@paquier.xyz>

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:13:02Z

Lists: pgsql-hackers

> 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.

correct, there is precedence for this.

This seems like the best way to proceed.

--

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