> 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.
I think plan_node_id is probably the least controversial because that value comes straight from core, and different extensions cannot have their own interpretation of what that value could be. Computing a plan_id is even more open for interpretation than it is for query_id perhaps, which is why giving this ability to extensions will be useful. Different extensions may choose to compute a plan_id different ways, but they all should be able to push this value into core, and this is what this patch will allow for. FWIW, Lukas did start a Wiki [0] to open the discussion for what parts of the plan should be used to compute a plan_id, and maybe we can in the future compite a plan_id in core by default. > > 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. correct. This was also recently raised in the "making Explain extensible" [0] thread also. That is the nature of extensions, and coordination is required. [0] https://wiki.postgresql.org/wiki/Plan_ID_Jumbling [1] https://www.postgresql.org/message-id/CA%2BTgmoZ8sTodL-orXQm51_npNxuDAS86BS5kC8t0LULneShRbg%40mail.gmail.com -- Sami Imseih Amazon Web Services (AWS)
