From: | Lukas Fittl <lukas(at)fittl(dot)com> |
---|---|
To: | Michael Paquier <michael(at)paquier(dot)xyz> |
Cc: | Sami Imseih <samimseih(at)gmail(dot)com>, 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 18:47:40 |
Message-ID: | CAP53PkwE9Anrw_AdTpC05PCjYMAC12c2OZuHmjzTwfcnZCWBMA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sun, Mar 23, 2025 at 9:43 PM Michael Paquier <michael(at)paquier(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Nathan Bossart | 2025-03-24 19:06:13 | Re: [PATCH] SVE popcount support |
Previous Message | Nathan Bossart | 2025-03-24 18:45:27 | Re: vacuum_truncate configuration parameter and isset_offset |