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
