Re: track generic and custom plans in pg_stat_statements

On 28/7/2025 08:18, Michael Paquier wrote:
> We could decide if a few more of the internal "fake" ones are worth
> subdividing, but I am feeling that this is kind of OK to start with.
> If we want more granularity, I was wondering about some bits to be
> able to mix one or more of these categories, but they are all
> exclusive as far as I know.
It looks good, but doesn't it seem too narrow?

For the sake of tracking queries, their parse tree and versions of the
plan, it seems worth adding an ext_list field to the Query and
PlannedStmt structures with a convention to add only Extensible nodes.
The core will be responsible only for copying this list from the
Query::ext_list to PlannedStmt::ext_list inside a correct memory
context.

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.

--
regards, Andrei Lepikhov