From: Tom Lane <tgl@sss.pgh.pa.us>
To: Sami Imseih <samimseih@gmail.com>
cc: Michael Paquier <michael@paquier.xyz>,
 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>
Subject: Re: track generic and custom plans in pg_stat_statements
In-reply-to: 
 <CAA5RZ0t54uP+O2dGZCoYfzOU_wcT2trVL65GdZB00RiLDs9BCg@mail.gmail.com>
References: <a0432b5d-84e1-4678-9963-bf5ecb749dd0@gmail.com>
 <CAA5RZ0sX=ZUZ0tFa3c3bQ4BWN4g7RbGUhg60GkP=5P-+XLJywA@mail.gmail.com>
 <CAA5RZ0tA43qf1HF1g6oYUGNBGFr23F29pf4F9Hymp2z8PyTsPg@mail.gmail.com>
 <aIBTulWwle8XseNt@paquier.xyz> <aIHarYaprfxOl7bU@paquier.xyz>
 <CAMMNXX=9Z-OiLLMOk0o8DJX9tNs5MA_qYWJ4VNFZbMPywBYQ8w@mail.gmail.com>
 <1647760.1753369510@sss.pgh.pa.us>
 <CAA5RZ0sxC0=2wZ-QaRB7FdMmQ4_BYKG=X+gdDGHnS6KTrfgLQA@mail.gmail.com>
 <1673684.1753379027@sss.pgh.pa.us>
 <CAA5RZ0sQuoHJsGc-dJV15yYURuXsOp2pwr9hLAk+pcm7=MAK2w@mail.gmail.com>
 <aILaHupXbIGgF2wJ@paquier.xyz>
 <CAA5RZ0t54uP+O2dGZCoYfzOU_wcT2trVL65GdZB00RiLDs9BCg@mail.gmail.com>
Comments: In-reply-to Sami Imseih <samimseih@gmail.com>
	message dated "Fri, 25 Jul 2025 10:29:01 -0500"
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-ID: <1933905.1753462272.1@sss.pgh.pa.us>
Content-Transfer-Encoding: 8bit
Date: Fri, 25 Jul 2025 12:51:12 -0400
Message-ID: <1933906.1753462272@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/1933906.1753462272%40sss.pgh.pa.us>
Precedence: bulk

Sami Imseih <samimseih@gmail.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.

			regards, tom lane