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: Andrei Lepikhov <lepihov@gmail.com>
Cc: Michael Paquier <michael@paquier.xyz>, 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-30T19:05:09Z
Lists: pgsql-hackers

Attachments

> > The term "NOT_SET" makes me itch a little bit, even if there is an
> > existing parallel with OverridingKind.  Perhaps your proposal is OK,
> > still how about "UNKNOWN" instead to use as term for the default?
> +1 to "UNKNOWN".

We currently use both UNKNOWN and NOT_SET in different places.
However, I'm okay with using UNKNOWN, and I've updated it in v16.

> But generally, classification in the PlannedStmtOrigin structure seems a
> little strange: a generic plan has a qualitative difference from any
> custom one. And any other plan also will be generic or custom, doesn't
> it?

I am not sure I understand the reasoning here. Can you provide more details/
specific examples?

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