| From: | Andrei Lepikhov <lepihov(at)gmail(dot)com> |
|---|---|
| To: | Sami Imseih <samimseih(at)gmail(dot)com> |
| Cc: | Michael Paquier <michael(at)paquier(dot)xyz>, 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-22 20:12:04 |
| Message-ID: | 09a82e0c-8c37-4366-9807-6553fa83a3b0@gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 7/22/25 19:13, Sami Imseih wrote:
>> It may be more efficient to set the is_generic_plan option at the top
>> plan node (PlannedStmt) and reference it wherever necessary. To identify
>> a cached plan, we may consider pushing the CachedPlan/CachedPlanSource
>> pointer down throughout pg_plan_query and maintaining a reference to the
>> plan (or simply setting a boolean flag) at the same location — inside
>> the PlannedStmt.
>
> We will need a field to store an enum. let's call it CachedPlanType
> with the types of cached plan. We need to be able to differentiate
> when cached plans are not used, so a simple boolean is not
> sufficient.
Sure. But I modestly hope you would add a CachedPlanSource pointer
solely to the PlannedStmt and restructure it a little as we discussed
above. And no new structures are needed. Am I wrong?
--
regards, Andrei Lepikhov
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Sami Imseih | 2025-07-22 20:28:24 | Re: track generic and custom plans in pg_stat_statements |
| Previous Message | Joel Jacobson | 2025-07-22 20:07:20 | [PATCH] Optimize ProcSignal to avoid redundant SIGUSR1 signals |