> 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)
