public inbox for [email protected]
help / color / mirror / Atom feedFrom: Michael Paquier <[email protected]>
To: Sami Imseih <[email protected]>
Cc: Lukas Fittl <[email protected]>
Cc: PostgreSQL Hackers <[email protected]>
Cc: Marko M <[email protected]>
Cc: Alvaro Herrera <[email protected]>
Cc: Julien Rouhaud <[email protected]>
Subject: Re: [PATCH] Optionally record Plan IDs to track plan changes for a query
Date: Wed, 12 Feb 2025 09:08:00 +0900
Message-ID: <[email protected]> (raw)
In-Reply-To: <CAA5RZ0t80hP2aTv97QtEJy39GkxKmDBVDiTBApfiuTa4O=TEWQ@mail.gmail.com>
References: <[email protected]>
<CAP53Pkw1QJHH9UDjkArS=XdAxtK7XWMpZLGHnVMDmhRTp_HYYw@mail.gmail.com>
<[email protected]>
<CAA5RZ0vM9AsEqvKued2drKZJ1opt3wbYaDbxGzi-khkNzwn7og@mail.gmail.com>
<[email protected]>
<CAA5RZ0sfRbd1xcq_oHNA0TPr57yM8qkg-GoD6A0nUfyxZhs33Q@mail.gmail.com>
<CAP53PkxocbNr+eRag3FEJp3-7S1U80FspOg8UQjO902TWMG=6A@mail.gmail.com>
<CAA5RZ0u6yJdFL=p5vdpbZFS-2YY+Z6vtzmt4gejgZa3RcNiWMQ@mail.gmail.com>
<[email protected]>
<CAA5RZ0t80hP2aTv97QtEJy39GkxKmDBVDiTBApfiuTa4O=TEWQ@mail.gmail.com>
On Mon, Feb 10, 2025 at 02:02:10PM -0600, Sami Imseih wrote:
> I am OK with moving away from "jumble" in-lieu of something else, but
> my thoughts are we should actually call this process "fingerprint"
> ( a term we already use in the queryjumblefuncs.c comment ).
> A fingerprint consists of all the interesting parts of a node tree that are
> appended and the final product is a hash of this fingerprint ( i.e. queryId )
> For node attributes we can specify "fingerprint_ignore"
> or "no_fingerprint". What do you think?
I think that I have a long history of showing a bad naming sense, that
I've done some follow-up API renames even on stable branches because
folks didn't like some names, and that I have a reputation for that on
these lists. :D
Wikipedia seems to agree with you that "fingerprint" would fit for
this purpose, though:
https://en.wikipedia.org/wiki/Fingerprint_(computing)
Has anybody any comments about that? That would be a large renaming,
but in the long term is makes sense if we want to apply that to more
than just parse nodes and query strings. If you do that, it impacts
the file names and the properties, that are hidden in the backend for
most of it, except the entry API and JumbleState. This last part
impacts some extensions and I have been maintaining one a bit
(pg_hint_plan).
>> The concept of location does not apply to plans, based on the
>> current proposal, so perhaps we should talk about "query normalization
>> location"?
>
> Are you referring to JUMBLE_LOCATION? and whether to keep it in
> queryjumblefuncs.c ( or jumblefuncs.c as is being proposed )?
Yes, I am referring to the existing jumble location. I don't quite
see how it fits with the plan part because we don't really have
locations to track.
Point worth noting, Alvaro has mentioned that he was planning to look
at the pgss patch with IN clauses:
https://www.postgresql.org/message-id/[email protected]
Adding him in CC here for awareness, but I can see that both of you
are involved on the other thread, as well. Also adding Julien in CC,
as he has some out-of-core extension code that depends on the jumbling
structures if I recall correctly.
--
Michael
Attachments:
[application/pgp-signature] signature.asc (833B, 2-signature.asc)
download
view thread (34+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected]
Subject: Re: [PATCH] Optionally record Plan IDs to track plan changes for a query
In-Reply-To: <[email protected]>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox