Re: Proposal - Allow extensions to set a Plan Identifier
Andrei Lepikhov <lepihov@gmail.com>
From: Andrei Lepikhov <lepihov@gmail.com>
To: Sami Imseih <samimseih@gmail.com>, Michael Paquier <michael@paquier.xyz>
Cc: Bertrand Drouvot <bertranddrouvot.pg@gmail.com>,
pgsql-hackers <pgsql-hackers@postgresql.org>, Lukas Fittl <lukas@fittl.com>
Date: 2025-03-23T07:25:42Z
Lists: pgsql-hackers
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Allow plugins to set a 64-bit plan identifier in PlannedStmt
- 2a0cd38da5cc 18.0 landed
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