Feedback-ID: i0fe9450f:Fastmail
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
From: Michael Paquier <michael@paquier.xyz>
Mime-Version: 1.0 (1.0)
Subject: Re: Refactor query normalization into core query jumbling
Date: Sat, 28 Mar 2026 10:42:09 +0900
Message-Id: <8437F4D0-9DFB-4045-9318-CC3C5BA2E267@paquier.xyz>
References: 
 <CAA5RZ0ui6JSDPQDs2RW7eBDvrH_t_xg8bhUM8FaxawU8wDoMFg@mail.gmail.com>
Cc: Lukas Fittl <lukas@fittl.com>, zengman <zengman@halodbtech.com>,
 pgsql-hackers <pgsql-hackers@postgresql.org>,
 Julien Rouhaud <rjuju123@gmail.com>
In-Reply-To: 
 <CAA5RZ0ui6JSDPQDs2RW7eBDvrH_t_xg8bhUM8FaxawU8wDoMFg@mail.gmail.com>
To: Sami Imseih <samimseih@gmail.com>
Archived-At: 
 <https://www.postgresql.org/message-id/8437F4D0-9DFB-4045-9318-CC3C5BA2E267%40paquier.xyz>
Precedence: bulk


> On Mar 28, 2026, at 2:09, Sami Imseih <samimseih@gmail.com> wrote:
> 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.

This is an interesting remark. One problem with any patches presented yet is=
 that we don=E2=80=99t attach the lengths as part of the in-core query jumbl=
ing procedure: we plug the lengths later using the same structure as the que=
ry jumbling. It seems to me that this is half-baked overall. I think that we=
 don=E2=80=99t want to pay the extra length computation in the core query ju=
mbling at the end, then why does it make sense to include the lengths in the=
 JumbleState structure at all? Shouldn=E2=80=99t we use a different structur=
e filled inside PGSS for this purpose rather than reuse the same thing for P=
GSS and the in-core part (don=E2=80=99t have the code in front of me now).
--
Michael