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
