| From: | Michael Paquier <michael(at)paquier(dot)xyz> |
|---|---|
| To: | Sami Imseih <samimseih(at)gmail(dot)com> |
| Cc: | 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-21 23:07:42 |
| Message-ID: | aH7IPp_Hku02xHP2@paquier.xyz |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Mon, Jul 21, 2025 at 04:47:31PM -0500, Sami Imseih wrote:
> Last week I published a v11 that adds a field to QueryDesc, but as I thought
> about this more, how about we just add 2 bool fields in QueryDesc->estate
> ( es_cached_plan and es_is_generic_plan ), a field in CachedPlan (
> is_generic_plan )
> and after ExecutorStart, and if we have a cplan, we set the
> appropriate plan cache
> mode value. I think it's better to confine these new fields in Estate
> rather than
> at a higher level like QueryDesc. See v12.
Yes, I think that this is a much better idea to isolate the whole
concept and let pgss grab these values. We have lived with such
additions for monitoring in EState a few times already, see for
example de3a2ea3b264 and 1d477a907e63 that are tainted with my
fingerprints.
--
Michael
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Sami Imseih | 2025-07-21 23:13:02 | Re: track generic and custom plans in pg_stat_statements |
| Previous Message | Michael Paquier | 2025-07-21 23:02:52 | Re: Verify predefined LWLocks tranches have entries in wait_event_names.txt |