On Sat, Mar 22, 2025 at 11:50:06PM +0100, Andrei Lepikhov wrote: > planId actually looks less controversial than queryId or plan_node_id. At > the same time, it is not free from the different logic that extensions may > incorporate into this value: I can imagine, for example, the attempt of > uniquely numbering plans related to the same queryId, plain hashing of the > plan tree, hashing without constants, etc.
One plan ID should have one single query ID, but the opposite may be not necessarily true: a query ID could be associated with multiple plan patterns (aka multiple plan IDs). What this offers is that we know about which plan one query is currently using in live, for a given query ID. > So, it seems that extensions may conflict with the same field. Are we sure > that will happen if they are loaded in different orders in neighbouring > backends? Depends on what kind of computation once wants to do, and surely without some coordination across the extensions you are using these cannot be shared, but it's no different from the concept of a query ID. The use cases I've seen where this field is useful is when splitting code that uses the planner hook for several purposes across more than one extension. Three of them which are independent, still want to treat know about a plan ID: - Set/get an existing node tree plan based on a specific ID. - Hash calculation of a tree (like Lukas proposal). - Statistics related to the plan tree used (aka custom cumulative stats play here). > I'm not very good at stat collector guts, but would it be possible to allow > extensions to report their state in standard tuple format? In that case, > doubts about queryId or planId may be resolved. I am not exactly sure what you mean here. We are only going to have one plan ID set for each query execution. Any stats plan data related to a plan ID surely needs to be upper-bounded if you don't want to bloat pgstats, with the query ID of the query string it relates to stored in it and the plan ID used as hash key, but it does not change that we're only going to always have one single plan ID in a PlannedStmt or in a backend entry doing a query execution, like a query ID. -- Michael
signature.asc
Description: PGP signature
