Re: [PATCH] Optionally record Plan IDs to track plan changes for a query

On 3/18/25 08:31, Michael Paquier wrote:
> On Thu, Feb 13, 2025 at 10:44:33AM -0600, Sami Imseih wrote:
>> The reason for the change is because "query jumble" will no longer
>> make sense if the jumble code can now be used for other types of
>> trees, such as Plan.
>>
>> I do agree that this needs a single-threaded discussion to achieve a
>> consensus.
> 
> FWIW, I was playing with a sub-project where I was jumbling a portion
> of nodes other than Query, and it is annoying to not have a direct
> access to jumbleNode().  So, how about doing the refactoring proposed
> in v5-0002 with an initialization routine and JumbleNode() as the
> entry point for the jumbling, but not rename the existing files
> queryjumblefuncs.c and queryjumble.h?  That seems doable for this
> release, at least.
It seems pretty helpful to me. Having a code for hashing an expression 
or subquery, we may design new optimisations. I personally have such a 
necessity in a couple of planner extensions.

At the same time, generalising jumbling code we may decide to work on 
the JumbleState structure: code related to constant locations may be 
replaced with callbacks - let the caller decide what action to take on 
each node (not only constants). Of course, it is not for current release.

> 
> I don't think that we should expose AppendJumble(), either.
Agree


-- 
regards, Andrei Lepikhov