Horton

Re: track generic and custom plans in pg_stat_statements

Sami Imseih <samimseih@gmail.com>

View thread View on postgr.es
From: Sami Imseih <samimseih@gmail.com>
To: Michael Paquier <michael@paquier.xyz>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, 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-29T22:08:09Z
Lists: pgsql-hackers

Attachments

> > Attached is my counter-proposal, where I have settled down to four
> > categories of PlannedStmt:
> > - "standard" PlannedStmt, when going through the planner.
> > - internally-generated "fake" PlannedStmt.
> > - custom cache
> > - generic cache
>
> Thanks for the update! I plan on reviewing this tomorrow.

The only comment I have is I think we need a NOT_SET
member, so it can simplify the life of extensions that have code
paths which may or may not have a PlannedStmt, such as
pgss_store. In pgss_store, I don't want to pass the entire PlannedStmt,
nor do I want to pass PLAN_STMT_INTERNAL in the call during
post_parse_analyze, in which case we don't have a plan. Using
PLAN_STMT_INTERNAL as a default value if odd.

v15 includes the change with the above as well as the pg_stat_statements
changes.


--
Sami

Commits

  1. pg_stat_statements: Add counters for generic and custom plans

  2. Rename CachedPlanType to PlannedStmtOrigin for PlannedStmt

  3. Introduce field tracking cached plan type in PlannedStmt