From: | Ilia Evdokimov <ilya(dot)evdokimov(at)tantorlabs(dot)com> |
---|---|
To: | Sami Imseih <samimseih(at)gmail(dot)com> |
Cc: | Greg Sabino Mullane <htamfids(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: track generic and custom plans in pg_stat_statements |
Date: | 2025-03-10 11:01:41 |
Message-ID: | b33a4d04-6cbd-49d4-ba9f-b2b001a154d5@tantorlabs.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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.
From | Date | Subject | |
---|---|---|---|
Next Message | Zhijie Hou (Fujitsu) | 2025-03-10 11:07:23 | RE: Selectively invalidate caches in pgoutput module |
Previous Message | Shubham Khanna | 2025-03-10 11:01:02 | Re: Adding a '--clean-publisher-objects' option to 'pg_createsubscriber' utility. |