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

From Ilia Evdokimov
Subject Re: track generic and custom plans in pg_stat_statements
Date
Msg-id b33a4d04-6cbd-49d4-ba9f-b2b001a154d5@tantorlabs.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 06.03.2025 18:04, Sami Imseih wrote:
2. Should we add Assert(kind == PGSS_EXEC) at this place  to ensure that
generic_plan_calls and custom_plan_calls are only incremented when
appropriate?


I don't think an assert is needed here. There is an assert at the start of
the block for PGSS_EXEC and PGSS_PLAN, but cplan is only available
in the executor.


You're right! Moreover, I didn't account for the fact that we pass NULL to pgss_ProcessUtility. In that case, Assert shouldn't be here.

I don't quite understand why do we need to differentiate between PLAN_CACHE_STATUS_GENERIC_PLAN_BUILD and PLAN_CACHE_STATUS_GENERIC_PLAN_REUSE? We could simply keep PLAN_CACHE_STATUS_GENERIC_PLAN_REUSE. I don't think users would see much of a difference in either pg_stat_statements or EXPLAIN.

As for EXPLAIN, maybe we should include this in VERBOSE mode?

--
Best regards,
Ilia Evdokimov,
Tantor Labs LLC.

pgsql-hackers by date:

Previous
From: Shubham Khanna
Date:
Subject: Re: Adding a '--clean-publisher-objects' option to 'pg_createsubscriber' utility.
Next
From: "Zhijie Hou (Fujitsu)"
Date:
Subject: RE: Selectively invalidate caches in pgoutput module