Re: track generic and custom plans in pg_stat_statements

From: Sami Imseih <samimseih(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Michael Paquier <michael(at)paquier(dot)xyz>, Andrei Lepikhov <lepihov(at)gmail(dot)com>, Greg Sabino Mullane <htamfids(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Nikolay Samokhvalov <nik(at)postgres(dot)ai>, Ilia Evdokimov <ilya(dot)evdokimov(at)tantorlabs(dot)com>
Subject: Re: track generic and custom plans in pg_stat_statements
Date: 2025-07-25 19:34:07
Message-ID: CAA5RZ0t4A4PVLHK5DPZWCsZvtviLf==PGG5eiy6Bm0DCpchHyQ@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> Sami Imseih <samimseih(at)gmail(dot)com> writes:
> >> Perhaps CachedPlanType is
> >> misnamed, though, would it be more suited to name that as a sort of
> >> "origin" or "source" field concept? We want to know which which
> >> source we have retrieved a plan that a PlannedStmt refers to.
>
> > Hmm, I’m not sure I see this as an improvement. In my opinion,
> > CachedPlanType is a clear name that describes its purpose.
>
> 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?

I can see that being useful, If I understood that correctly.

--
Sami

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2025-07-25 20:49:52 Re: Fixing memory leaks in postgres_fdw
Previous Message Andrew Dunstan 2025-07-25 19:31:47 Re: Non-text mode for pg_dumpall