From: | Sami Imseih <samimseih(at)gmail(dot)com> |
---|---|
To: | Lukas Fittl <lukas(at)fittl(dot)com> |
Cc: | Michael Paquier <michael(at)paquier(dot)xyz>, Andrei Lepikhov <lepihov(at)gmail(dot)com>, Bertrand Drouvot <bertranddrouvot(dot)pg(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Proposal - Allow extensions to set a Plan Identifier |
Date: | 2025-04-01 15:58:30 |
Message-ID: | CAA5RZ0vP190G3MLuhAdcE9pymE_kZyHOOQ7R218SjshQm-Y7XQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Mar 31, 2025 at 1:28 PM Lukas Fittl <lukas(at)fittl(dot)com> wrote:
>
> On Tue, Mar 25, 2025 at 8:12 PM Sami Imseih <samimseih(at)gmail(dot)com> wrote:
>>>
>>> So this comes down to forking the Postgres code to do the job. What I
>>> had in mind was a slightly different flow, where we would be able to
>>> push custom node attributes between the header parsing and the
>>> generation of the extension code. If we do that, there would be no
>>> need to fork the Postgres code: extensions could force the definitions
>>> they want to the nodes they want to handle, as long as these do not
>>> need to touch the in-core query jumble logic, of course.
>>
>>
>> Allowing extensions to generate code for custom node attributes could be
>> taken up in 19. What about for 18 we think about exposing AppendJumble,
>> JUMBLE_FIELD, JUMBLE_FIELD_SINGLE and JUMBLE_STRING?
>
>
> +1, I think exposing the node jumbling logic + ability to jumble values for extensions would make a big difference to get into 18, specifically for allowing extensions to do plan ID calculations efficiently
I think getting these APIs into 18 is super important, especially with
the optimizations made in
ad9a23bc4; I will reiterate that extension developers should not have
to re-invent these
wheels :)
> I've also intentionally reduced the API surface area and not allowed initializing a jumble state that records constant locations / not exported RecordConstLocations.
> I think the utility of that seems less clear (possibly out-of-core queryid customization with a future extension hook in jumbleNode) and requires more refinement.
I agree with that primarily because I don't know of the use case at
this time in which
an extension will need to record a constant location.
I reviewed the patch and I only have one comment. I still think
we need an Assert inside RecordConstantLocation to make sure clocations
is allocated if the caller intends to record constant locations.
RecordConstLocation(JumbleState *jstate, int location, bool squashed)
{
+ Assert(jstate->clocations);
+
--
Sami Imseih
Amazon Web Services (AWS)
From | Date | Subject | |
---|---|---|---|
Next Message | Noah Misch | 2025-04-01 16:07:27 | Re: AIO v2.5 |
Previous Message | Tom Lane | 2025-04-01 15:57:18 | macOS 15.4 versus strchrnul() |