public inbox for [email protected]
help / color / mirror / Atom feedFrom: Sami Imseih <[email protected]>
To: Lukas Fittl <[email protected]>
Cc: Michael Paquier <[email protected]>
Cc: zengman <[email protected]>
Cc: pgsql-hackers <[email protected]>
Cc: Julien Rouhaud <[email protected]>
Subject: Re: Refactor query normalization into core query jumbling
Date: Fri, 27 Mar 2026 12:09:04 -0500
Message-ID: <CAA5RZ0ui6JSDPQDs2RW7eBDvrH_t_xg8bhUM8FaxawU8wDoMFg@mail.gmail.com> (raw)
In-Reply-To: <CAP53Pkz0XqVoHv-pfq+i6Ngs5HX1TC=G6spHWGMpusARBZ0YbQ@mail.gmail.com>
References: <CAA5RZ0sbWmqdUBFo8JXMJe72pnwjxVY58htJ6pKbwnyQuRctQw@mail.gmail.com>
<CAP53PkxqGbPw5VzpacyJb2wTofYJadCoUmxV8s2o5tHzKznwbg@mail.gmail.com>
<CAA5RZ0t3-srmtaVNfzv0HEzXCa78eQDKYVak+3zgEccnKPZHHA@mail.gmail.com>
<CAA5RZ0t_CJs9ye1PPBy-e0ajZ-6FgKvNEoacW9keCtF_7Y2ycQ@mail.gmail.com>
<CAA5RZ0vEnNvp7_Ni8bWwh4GE53rg_YwNjqynQG=JpNu3YzzAWA@mail.gmail.com>
<CAP53PkzCzeDpg6dCzVrU17LCiCmRSWfEt-5dr4y+VHnTxKr_9w@mail.gmail.com>
<CAA5RZ0tzLhGxR3cCQtPs1=HeGWh0WDDBC1KDTgOh9x9u2gvy1Q@mail.gmail.com>
<CAP53PkyY7AhQ8jZDwtHokyEfpuHLxxDvtY7EmcasR_n80yLiRQ@mail.gmail.com>
<CAA5RZ0unJX_EwepME9NAuB=u8LjtRCU67FW6yMP07tFkJE5yRA@mail.gmail.com>
<CAP53PkycUYE6d_Pyt2BcxmTaq7v8qDt6LtBObVfsUt+WNWf0ug@mail.gmail.com>
<[email protected]>
<CAP53Pkz0XqVoHv-pfq+i6Ngs5HX1TC=G6spHWGMpusARBZ0YbQ@mail.gmail.com>
> On Thu, Mar 26, 2026 at 10:18 PM Michael Paquier <[email protected]> wrote:
> > This line of arguments is stronger for the normalization of the query
> > string. Why should the core code decide what a normalized string
> > should look like when it comes to the detection of the constants, if
> > any? Instead of a dollar-quoted number, we could enforce a bunch of
> > things, like a '?' or a '$woozah$' at these locations.
>
> Fair enough, though I haven't seen any extensions that do that in
> practice - its reasonable to have normalization result in a query
> string that's parsable again and can be passed to EXPLAIN
> (GENERIC_PLAN).
with regards to generate_normalized_query, AFAICT, the most common
case is extensions are using it for is dollar quoted number, but I agree
this one is a gray area.
> What if we only put the ComputeConstantLengths (as Sami had it in v7)
> in core, together with making JumbleState const?
I agree that ComputeConstantLengths should be in core. This one is
not a gray area IMO. The query jumble already records constant locations,
but leaves the lengths unset. ComputeConstantLengths is just the
completion of that work. There could be no other interpretation,
unlike generate_normalized_query, of what the lengths should be.
--
Sami Imseih
Amazon Web Services (AWS)
view thread (35+ 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]
Subject: Re: Refactor query normalization into core query jumbling
In-Reply-To: <CAA5RZ0ui6JSDPQDs2RW7eBDvrH_t_xg8bhUM8FaxawU8wDoMFg@mail.gmail.com>
* 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