Re: track generic and custom plans in pg_stat_statements

On 30/7/2025 09:20, Michael Paquier wrote:
> On Tue, Jul 29, 2025 at 05:08:09PM -0500, Sami Imseih wrote:
>> The only comment I have is I think we need a NOT_SET
>> member, so it can simplify the life of extensions that have code
>> paths which may or may not have a PlannedStmt, such as
>> pgss_store.
> 
> Okay by me for having a default that maps to something else than the
> rest.
> 
> +   PLAN_STMT_NOT_SET = 0,      /* origin not yet set */
> 
> The term "NOT_SET" makes me itch a little bit, even if there is an
> existing parallel with OverridingKind.  Perhaps your proposal is OK,
> still how about "UNKNOWN" instead to use as term for the default?
+1 to "UNKNOWN".

There may be various sources for query plans. For instance, in the plan 
freezing extension, I often bypass the standard planner completely by 
using a plan created in another backend and serialised in shared memory. 
Additionally, there is a concept of comparing hinted plans with those 
generated freely after an upgrade, which would serve as an extra source 
of plans.
One extra example - I sometimes build a 'referenced generic plan', using 
incoming constants as a source for clause selectivity calculations, 
building a generic plan, likewise SQL Server or Oracle implemented 
generics. It seems like a 'hybrid' type of plan ;).

But generally, classification in the PlannedStmtOrigin structure seems a 
little strange: a generic plan has a qualitative difference from any 
custom one. And any other plan also will be generic or custom, doesn't 
it? It is interesting information about the plan source, of course, but 
for the sake of performance analysis, it would be profitable to 
understand the type of plan. However, the last sentence may be a subject 
for another thread.

-- 
regards, Andrei Lepikhov