On 28/7/2025 08:46, Michael Paquier wrote:
> On Mon, Jul 28, 2025 at 08:41:29AM +0200, Andrei Lepikhov wrote:
>> It looks good, but doesn't it seem too narrow?
>
> For the use case of the thread which is to count the number of custom
> vs generic plans, it would be good enough.
Sure, no objections.
>
>> This minor change allows an extension to track a specific query from
>> the parse tree up to the end of execution and carry as much data as
>> needed. The extension (pg_stat_statements as well) may add all the
>> necessary data in the parse hook, planner hook, or any of the
>> execution hooks. With a trivial naming convention, Extensible nodes of
>> different extensions will not interfere.
>> To identify the cached plan, the GetCachedPlan hook may be introduced.
>
> Without knowing the actual use cases where these additions can be
> useful, introducing this extra amount of infrastructure may not be
> justified. Just my 2c and my impressions after studying the whole
> thread.
The case is as I already described: in Postgres, extensions have no way
to identify how their path hooks really influenced specific query plan
and its execution. During planning, they have only a pointer to the
Query structure, but at the end of execution, only a PlannedStmt is
available. I propose improving this 'blind' approach to planning.
The only argument I usually receive in response to such a proposal is to
add a beneficial example. The current pg_stat_statements change may be a
good example of the employment of such infrastructure, isn't it?
--
regards, Andrei Lepikhov
