Re: Proposal - Allow extensions to set a Plan Identifier - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: Proposal - Allow extensions to set a Plan Identifier
Date
Msg-id Z_Sm5GE2nOFzReUV@paquier.xyz
Whole thread Raw
In response to Re: Proposal - Allow extensions to set a Plan Identifier  (Lukas Fittl <lukas@fittl.com>)
List 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

Attachment

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: [PoC] Reducing planning time when tables have many partitions
Next
From: Tom Lane
Date:
Subject: Re: pg_dump/restore failure (dependency?) on BF serinus