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: Mon, 5 Jan 2026 19:01:12 -0600
Message-ID: <CAA5RZ0t3-srmtaVNfzv0HEzXCa78eQDKYVak+3zgEccnKPZHHA@mail.gmail.com> (raw)
In-Reply-To: <CAP53PkxqGbPw5VzpacyJb2wTofYJadCoUmxV8s2o5tHzKznwbg@mail.gmail.com>
References: <CAA5RZ0tZp5qU0ikZEEqJnxvdSNGh1DWv80sb-k4QAUmiMoOp_Q@mail.gmail.com>
<[email protected]>
<CAA5RZ0vQfE14HyfpoPXDRThVcdCkLgY_HGz+J2qLB9soNUE9QQ@mail.gmail.com>
<[email protected]>
<CAA5RZ0uLS9RrpO2roX7p3EHE4-VJkBsGAB970jrbo1-GRDAi0g@mail.gmail.com>
<[email protected]>
<CAA5RZ0sbWmqdUBFo8JXMJe72pnwjxVY58htJ6pKbwnyQuRctQw@mail.gmail.com>
<CAP53PkxqGbPw5VzpacyJb2wTofYJadCoUmxV8s2o5tHzKznwbg@mail.gmail.com>
>> 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.gma...
--
Sami Imseih
Amazon Web Services (AWS)
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: <CAA5RZ0t3-srmtaVNfzv0HEzXCa78eQDKYVak+3zgEccnKPZHHA@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