Re: track generic and custom plans in pg_stat_statements - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: track generic and custom plans in pg_stat_statements
Date
Msg-id aH7IPp_Hku02xHP2@paquier.xyz
Whole thread Raw
In response to Re: track generic and custom plans in pg_stat_statements  (Sami Imseih <samimseih@gmail.com>)
Responses Re: track generic and custom plans in pg_stat_statements
List 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

Attachment

pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: Verify predefined LWLocks tranches have entries in wait_event_names.txt
Next
From: Sami Imseih
Date:
Subject: Re: track generic and custom plans in pg_stat_statements