On 3/23/25 04:22, Sami Imseih wrote:
>> 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.
I meant the proposal to let extensions calculate this field. Someone may
want node_id to be unique inside the plan; for someone - it should
reflect the nature of the node, and it may be the same even inside one
plan, etc. In this case, it is highly controversial.
>
> 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.
That's why I worry about allowing extensions to compute it. Remember:
for now, an extension can't be sure that a conflicting one is not
already loaded in the backend. The code [1] may relieve this problem.
[1]
https://www.postgresql.org/message-id/flat/441661.1742683797@sss.pgh.pa.us#7640020deb6497fe049ac4839eaeb33d
--
regards, Andrei Lepikhov
