public inbox for [email protected]
help / color / mirror / Atom feedRe: [PATCH] Optionally record Plan IDs to track plan changes for a query
4+ messages / 4 participants
[nested] [flat]
* Re: [PATCH] Optionally record Plan IDs to track plan changes for a query
@ 2025-02-13 11:25 Alvaro Herrera <[email protected]>
2025-02-13 16:44 ` Re: [PATCH] Optionally record Plan IDs to track plan changes for a query Sami Imseih <[email protected]>
0 siblings, 1 reply; 4+ messages in thread
From: Alvaro Herrera @ 2025-02-13 11:25 UTC (permalink / raw)
To: Sami Imseih <[email protected]>; +Cc: Greg Sabino Mullane <[email protected]>; Michael Paquier <[email protected]>; Lukas Fittl <[email protected]>; PostgreSQL Hackers <[email protected]>; Marko M <[email protected]>; Julien Rouhaud <[email protected]>
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."
^ permalink raw reply [nested|flat] 4+ messages in thread
* Re: [PATCH] Optionally record Plan IDs to track plan changes for a query
2025-02-13 11:25 Re: [PATCH] Optionally record Plan IDs to track plan changes for a query Alvaro Herrera <[email protected]>
@ 2025-02-13 16:44 ` Sami Imseih <[email protected]>
2025-03-18 07:31 ` Re: [PATCH] Optionally record Plan IDs to track plan changes for a query Michael Paquier <[email protected]>
0 siblings, 1 reply; 4+ messages in thread
From: Sami Imseih @ 2025-02-13 16:44 UTC (permalink / raw)
To: Alvaro Herrera <[email protected]>; +Cc: Greg Sabino Mullane <[email protected]>; Michael Paquier <[email protected]>; Lukas Fittl <[email protected]>; PostgreSQL Hackers <[email protected]>; Marko M <[email protected]>; Julien Rouhaud <[email protected]>
> 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.
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
^ permalink raw reply [nested|flat] 4+ messages in thread
* Re: [PATCH] Optionally record Plan IDs to track plan changes for a query
2025-02-13 11:25 Re: [PATCH] Optionally record Plan IDs to track plan changes for a query Alvaro Herrera <[email protected]>
2025-02-13 16:44 ` Re: [PATCH] Optionally record Plan IDs to track plan changes for a query Sami Imseih <[email protected]>
@ 2025-03-18 07:31 ` Michael Paquier <[email protected]>
2025-03-18 09:12 ` Re: [PATCH] Optionally record Plan IDs to track plan changes for a query Andrei Lepikhov <[email protected]>
0 siblings, 1 reply; 4+ messages in thread
From: Michael Paquier @ 2025-03-18 07:31 UTC (permalink / raw)
To: Sami Imseih <[email protected]>; +Cc: Alvaro Herrera <[email protected]>; Greg Sabino Mullane <[email protected]>; Lukas Fittl <[email protected]>; PostgreSQL Hackers <[email protected]>; Marko M <[email protected]>; Julien Rouhaud <[email protected]>
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.
I don't think that we should expose AppendJumble(), either.
--
Michael
Attachments:
[application/pgp-signature] signature.asc (833B, 2-signature.asc)
download
^ permalink raw reply [nested|flat] 4+ messages in thread
* Re: [PATCH] Optionally record Plan IDs to track plan changes for a query
2025-02-13 11:25 Re: [PATCH] Optionally record Plan IDs to track plan changes for a query Alvaro Herrera <[email protected]>
2025-02-13 16:44 ` Re: [PATCH] Optionally record Plan IDs to track plan changes for a query Sami Imseih <[email protected]>
2025-03-18 07:31 ` Re: [PATCH] Optionally record Plan IDs to track plan changes for a query Michael Paquier <[email protected]>
@ 2025-03-18 09:12 ` Andrei Lepikhov <[email protected]>
0 siblings, 0 replies; 4+ messages in thread
From: Andrei Lepikhov @ 2025-03-18 09:12 UTC (permalink / raw)
To: Michael Paquier <[email protected]>; Sami Imseih <[email protected]>; +Cc: Alvaro Herrera <[email protected]>; Greg Sabino Mullane <[email protected]>; Lukas Fittl <[email protected]>; PostgreSQL Hackers <[email protected]>; Marko M <[email protected]>; Julien Rouhaud <[email protected]>
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
^ permalink raw reply [nested|flat] 4+ messages in thread
end of thread, other threads:[~2025-03-18 09:12 UTC | newest]
Thread overview: 4+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2025-02-13 11:25 Re: [PATCH] Optionally record Plan IDs to track plan changes for a query Alvaro Herrera <[email protected]>
2025-02-13 16:44 ` Sami Imseih <[email protected]>
2025-03-18 07:31 ` Michael Paquier <[email protected]>
2025-03-18 09:12 ` Andrei Lepikhov <[email protected]>
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox