Re: Proposal - Allow extensions to set a Plan Identifier

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

In response to

Browse pgsql-hackers by date

  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