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

From: Alvaro Herrera <[email-masked]>
Date: Thu, 13 Feb 2025 12:25:25 +0100

On 2025-Feb-12, Sami Imseih wrote:

> Greg S. Mullane wrote:
>
> > I agree fingerprint is the right final word. But "jumble" conveys
> > the *process* better than "fingerprinting".  I view it as jumbling
> > produces an object that can be fingerprinted.
> 
> hmm, "jumble" describes something that is scrambled
> or not in order, such as the 64-bit hash produced. It
> sounds like the final product.

I don't understand why we would change any naming here at all.  I think
you should be looking at a much broader consensus and plus-ones that a
renaming is needed.  -1 from me.

-- 
Álvaro Herrera        Breisgau, Deutschland  —  https://www.EnterpriseDB.com/
"No renuncies a nada. No te aferres a nada."

---

From: Sami Imseih <[email-masked]>
Date: Thu, 13 Feb 2025 10:44:33 -0600

> renaming is needed.  -1 from me.

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.

--

Sami

---

From: Michael Paquier <[email-masked]>
Date: Tue, 18 Mar 2025 16:31:06 +0900

> I do agree that this needs a single-threaded discussion to achieve a

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.

I don't think that we should expose AppendJumble(), either.
--
Michael

---

From: Andrei Lepikhov <[email-masked]>
Date: Tue, 18 Mar 2025 10:12:10 +0100

> queryjumblefuncs.c and queryjumble.h?  That seems doable for this
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