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: 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-28T06:18:18Z
Lists: pgsql-hackers

Attachments

On Fri, Jul 25, 2025 at 02:34:07PM -0500, Sami Imseih wrote:
> Sami Imseih <samimseih@gmail.com> writes:
>> I think Michael's got a point.  As of HEAD there are seven different
>> places that are setting this to PLAN_CACHE_NONE; who's to say that
>> pg_stat_statements or some other extension might not wish to
>> distinguish some of those sources?  At the very least, user-submitted
>> versus internally-generated queries might be an interesting
>> distinction.  I don't have a concrete proposal for a different
>> categorization than what we've got, but it seems worth considering
>> while we still have the flexibility to change it easily.
> 
> Sure, I get it now, I think. An example is the cached plan from a sql
> in a utility statement of a prepared statement, as an example. right?

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

We could decide if a few more of the internal "fake" ones are worth
subdividing, but I am feeling that this is kind of OK to start with.
If we want more granularity, I was wondering about some bits to be
able to mix one or more of these categories, but they are all
exclusive as far as I know.
--
Michael

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