Re: Proposal - Allow extensions to set a Plan Identifier
От | Andrei Lepikhov |
---|---|
Тема | Re: Proposal - Allow extensions to set a Plan Identifier |
Дата | |
Msg-id | 1347afa1-cdd7-4b12-aa7a-54471208ed6a@gmail.com обсуждение исходный текст |
Ответ на | Re: Proposal - Allow extensions to set a Plan Identifier (Sami Imseih <samimseih@gmail.com>) |
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: