Re: Proposal - Allow extensions to set a Plan Identifier
| От | Lukas Fittl |
|---|---|
| Тема | Re: Proposal - Allow extensions to set a Plan Identifier |
| Дата | |
| Msg-id | CAP53PkwE9Anrw_AdTpC05PCjYMAC12c2OZuHmjzTwfcnZCWBMA@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: Proposal - Allow extensions to set a Plan Identifier (Michael Paquier <michael@paquier.xyz>) |
| Ответы |
Re: Proposal - Allow extensions to set a Plan Identifier
|
| Список | pgsql-hackers |
On Sun, Mar 23, 2025 at 9:43 PM Michael Paquier <michael@paquier.xyz> wrote:
So I've applied the patch for now, to start with
something.
Thanks for committing that, I think that's a great starting point for 18!
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.
> 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 (or at least a pg_stat_plans in contrib that does its own tree walk) within the PG19 development cycle - I think plan IDs are actually less complicated than query IDs in terms of what should be considered unique - but maybe that's just my perspective :)
I'll be at PGConf.dev this year, would be great to do an unconference session to discuss this further.
Thanks,
Lukas
Lukas Fittl
В списке pgsql-hackers по дате отправления: