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

From Andrei Lepikhov
Subject Re: track generic and custom plans in pg_stat_statements
Date
Msg-id 09a82e0c-8c37-4366-9807-6553fa83a3b0@gmail.com
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 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



pgsql-hackers by date:

Previous
From: "Joel Jacobson"
Date:
Subject: [PATCH] Optimize ProcSignal to avoid redundant SIGUSR1 signals
Next
From: Sami Imseih
Date:
Subject: Re: track generic and custom plans in pg_stat_statements