MIME-Version: 1.0
References: <CAA5RZ0tZp5qU0ikZEEqJnxvdSNGh1DWv80sb-k4QAUmiMoOp_Q@mail.gmail.com>
 <aUT1eblRYpwB1nC7@ip-10-97-1-34.eu-west-3.compute.internal>
 <CAA5RZ0vQfE14HyfpoPXDRThVcdCkLgY_HGz+J2qLB9soNUE9QQ@mail.gmail.com>
 <tencent_2FF1F5A9360E2DD24C6478FB@qq.com> <CAA5RZ0uLS9RrpO2roX7p3EHE4-VJkBsGAB970jrbo1-GRDAi0g@mail.gmail.com>
 <aUtm47pcAhZ1Ix0B@paquier.xyz> <CAA5RZ0sbWmqdUBFo8JXMJe72pnwjxVY58htJ6pKbwnyQuRctQw@mail.gmail.com>
 <CAP53PkxqGbPw5VzpacyJb2wTofYJadCoUmxV8s2o5tHzKznwbg@mail.gmail.com>
In-Reply-To: <CAP53PkxqGbPw5VzpacyJb2wTofYJadCoUmxV8s2o5tHzKznwbg@mail.gmail.com>
From: Sami Imseih <samimseih@gmail.com>
Date: Mon, 5 Jan 2026 19:01:12 -0600
Message-ID: <CAA5RZ0t3-srmtaVNfzv0HEzXCa78eQDKYVak+3zgEccnKPZHHA@mail.gmail.com>
Subject: Re: Refactor query normalization into core query jumbling
To: Lukas Fittl <lukas@fittl.com>
Cc: Michael Paquier <michael@paquier.xyz>, zengman <zengman@halodbtech.com>, 
	pgsql-hackers <pgsql-hackers@postgresql.org>, Julien Rouhaud <rjuju123@gmail.com>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://www.postgresql.org/message-id/CAA5RZ0t3-srmtaVNfzv0HEzXCa78eQDKYVak%2B3zgEccnKPZHHA%40mail.gmail.com>
Precedence: bulk

>> backwards compatible. Basically, we keep JumbleState a non-constant,
>> but provide core APIs for any operation, such as
>> generate_normalized_query,
>> that needs to modify the state. So, my approach was not about enforcing a
>> read-only JumbleState, but about providing the API to dissuade an author
>> from modifying a JumbleState.

> Given the lack of public APIs to modify JumbleState today, I don't see how
> an extension would do
> modifications in a meaningful way, short of copying the code. I think we
> should be a bit bolder here in
> enforcing a convention, either clearly making it read-only or dropping the
> argument again.

Based on the discussion so far I am leaning towards making JumbleState
read-only as described here [0]. I don't see how we can drop JumbleState
completely from hooks, since normalization needs to occur on-demand
by the extension.

> 1) An extension that wants to display normalized query strings
>
> This seems to be the biggest kind of what I can find with code search.
> Extensions like pg_stat_monitor [1], that
> want to do something like pg_stat_statements, and have to copy a bunch of
> normalization code today that is 1:1 what
> Postgres does. Such extensions don't need the JumbleState argument if they
> can get the normalized text directly.

Yes, I don't know how that's possible; besides generating the normalized
string during JumbleQuery and making it available to post_parse_analyze
hook ( and other executor hooks ). But this also means we are incurring
the normalization overhead for every execution.

> 2) An extension that wants to capture parameter values
>
> Some extensions may want to remember additional context for normalized
> queries, like pg_tracing's logic for
> optionally passing parameter values (post normalization) in the trace
> context [2]. If we kept passing a read-only
> JumbleState then such extensions could presumably still get this, but I
> wonder if it wouldn't be better for core to
> have a helper for this?

This could be like a core GenerateNormalizedQuery which can optionally
track the constant values. That will be an enhancement to normalization
and a new requirement.

[0] https://www.postgresql.org/message-id/CAA5RZ0sbWmqdUBFo8JXMJe72pnwjxVY58htJ6pKbwnyQuRctQw%40mail.gmail.com

--
Sami Imseih
Amazon Web Services (AWS)