| 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-03-24 19:36:05 |
| Message-ID: | CAA5RZ0udib3f1_chVjewBrp9KLygc7ftmFyTxcHu9tzSXd9Ecg@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
> Ideally we can also land the jumble funcs work in the other thread to allow extensions to re-use the
> in-core logic for jumbling expressions found in plan node trees.
IIUC, there should be a refactor I am working on at this moment to make that
possible [0]
>> > 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.
>>
>> Let's see where this leads.. I suspect that this is going to take
>> some time, assuming that we're ever able to settle on a clear
>> definition. Perhaps we will, or perhaps we will not.
>
>
> I think there is a good chance we'll land on a reasonable planid calculation for core
I agree
> I'll be at PGConf.dev this year, would be great to do an unconference session to discuss this further.
That will be a good idea!
[0] https://www.postgresql.org/message-id/Z9khOo14yzZHCnmn%40paquier.xyz
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Nathan Bossart | 2025-03-24 20:04:39 | Re: vacuum_truncate configuration parameter and isset_offset |
| Previous Message | Nikolay Shaplov | 2025-03-24 19:35:41 | Re: vacuum_truncate configuration parameter and isset_offset |