public inbox for [email protected]  
help / color / mirror / Atom feed
From: 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