Message-ID: <c7db8652-6af8-46ec-8b0b-1a1c6748c075@gmail.com>
Date: Tue, 18 Mar 2025 10:12:10 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] Optionally record Plan IDs to track plan changes for a
 query
To: Michael Paquier <michael@paquier.xyz>, Sami Imseih <samimseih@gmail.com>
Cc: Alvaro Herrera <alvherre@alvh.no-ip.org>,
 Greg Sabino Mullane <htamfids@gmail.com>, Lukas Fittl <lukas@fittl.com>,
 PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>,
 Marko M <marko@pganalyze.com>, Julien Rouhaud <rjuju123@gmail.com>
References: 
 <CAA5RZ0vkNBGmz_ffiKN8vqD9S2rWH=dLXOM9d3uqN+qhefHBxw@mail.gmail.com>
 <202502131125.3kk6id4tcrtv@alvherre.pgsql>
 <CAA5RZ0vnAdfJjAQQjxYLjS-zrkXBjwRrT=+uSFP7YPtWioErig@mail.gmail.com>
 <Z9khOo14yzZHCnmn@paquier.xyz>
Content-Language: en-AU
From: Andrei Lepikhov <lepihov@gmail.com>
In-Reply-To: <Z9khOo14yzZHCnmn@paquier.xyz>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
 <https://www.postgresql.org/message-id/c7db8652-6af8-46ec-8b0b-1a1c6748c075%40gmail.com>
Precedence: bulk

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