public inbox for [email protected]
help / color / mirror / Atom feedFrom: Sami Imseih <[email protected]>
To: Michael Paquier <[email protected]>
Cc: Lukas Fittl <[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: Tue, 31 Mar 2026 21:53:48 -0500
Message-ID: <CAA5RZ0ufGxCCoPBHKV2mLo9CzHe83w1L-mhx5XHU4axXkMHirw@mail.gmail.com> (raw)
In-Reply-To: <[email protected]>
References: <CAA5RZ0ui6JSDPQDs2RW7eBDvrH_t_xg8bhUM8FaxawU8wDoMFg@mail.gmail.com>
<[email protected]>
<CAP53Pkwb2f288Ji2s9ZZTL0_PEyYCZpQjBtD63X_s+yUB3YORA@mail.gmail.com>
<CAA5RZ0vrXNndS6rGx43q+h9JNtxnUzZnxgP_zWSc9LHXS36bXg@mail.gmail.com>
<[email protected]>
> >> I see where you're coming from on that, but I don't think we can
> >> remove anything here in practice:
> >
> > Yes. Not unless we want to rely on the parser to track the lengths in
> > Const, which could be invasive, but I have not looked into it.
>
> Hmm. We may not want to get down to that, still that would be
> cheaper than reprocessing the parsing of the query string twice.
Although unless an extension, at least pg_stat_statements, should
not be doing this double work often, and if it is it is due to heavy
churn on entries.
> >> I still think it'd be reasonable for us to include
> >> ComputeConstantLengths in core to complete the picture of what we're
> >> doing with _jumbleElements and the length field already anyway. Its
> >> basically a way to fully hydrate the partially filled out JumbleState
> >> from the initial jumble.
> >
> > I fully agree, ComputeConstantLengths is an optional post-jumble-query step
> > for a consumer that wishes to calculate the lengths. The length calculation
> > is not unique to a plug-in, so in my mind the work it's doing is core
> > jumbling functionality.
>
> Okay. I could fall into that for this release. Marking the
> JumbleState as a const is the most important piece here.
I do agree.
> I'm +-0 regarding this routine, but I can also see your point about how it's
> useful to give at least the option to extensions to have a
> recomputation of the Const lengths, the same way as PGSS. What are
> the extensions that would use that?
https://github.com/search?q=fill_in_constant_lengths&type=code
A few well-known extensions/tools out there based on a Github search.
--
Sami
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]
Subject: Re: Refactor query normalization into core query jumbling
In-Reply-To: <CAA5RZ0ufGxCCoPBHKV2mLo9CzHe83w1L-mhx5XHU4axXkMHirw@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