From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Sami Imseih <samimseih(at)gmail(dot)com> |
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 16:51:12 |
Message-ID: | 1933906.1753462272@sss.pgh.pa.us |
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.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Fabrízio de Royes Mello | 2025-07-25 17:06:12 | Re: Use PqMsg_* macros in basebackup_copy.c |
Previous Message | Tomas Vondra | 2025-07-25 16:23:14 | Re: PoC: adding CustomJoin, separate from CustomScan |