From: | Michael Paquier <michael(at)paquier(dot)xyz> |
---|---|
To: | Lukas Fittl <lukas(at)fittl(dot)com> |
Cc: | Sami Imseih <samimseih(at)gmail(dot)com>, David Rowley <dgrowleyml(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-04-08 04:32:36 |
Message-ID: | Z_Sm5GE2nOFzReUV@paquier.xyz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Apr 07, 2025 at 06:11:06PM -0700, Lukas Fittl wrote:
> However, since we're basically at feature freeze (and it seems unlikely
> this gets into 18), I have a quick alternate proposal:
>
> What if, for 18, we just make DoJumble exported to be used by plugins?
Yes, I am not planning to rush that into v18. Things are what they
are for this release, I am afraid. While looking at your patch, I'm
not liking much the fact that this exposes AppendJumbleNN() for
extensions, which should be something that remains internal to
queryjumblefuncs.c. I don't think that we should do that.
> DoJumble was added in David's fix for NULL handling in f31aad9b0, but
> remained local to queryjumblefuncs.c. Exporting that would enable an
> extension to jumble expression fields contained in plan nodes and get the
> hash value, and then do its own hashing/jumbling of the plan nodes as it
> sees fit, without reinventing the wheel. I'll be around the next hours to
> make a quick patch (though its basically just two lines) if this is of
> interest.
I think that David is getting it right with its initial set of
InitJumble() and DoJumble() interfaces, where it is possible to do a
computation based on a Node. It is local to queryjumblefuncs.c
because we don't need it elsewhere now, but the question is really how
much would be relevant enough for extension looking at potential Node
computations. To me, it's pretty much a sign that we should think
more carefully about the interface to provide here, and not rush
things.
--
Michael
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2025-04-08 04:48:34 | Re: pg_dump/restore failure (dependency?) on BF serinus |
Previous Message | Tom Lane | 2025-04-08 04:20:04 | Re: [PoC] Reducing planning time when tables have many partitions |