Re: Refactor query normalization into core query jumbling

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Lukas Fittl <lukas(at)fittl(dot)com>
Cc: Sami Imseih <samimseih(at)gmail(dot)com>, zengman <zengman(at)halodbtech(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Julien Rouhaud <rjuju123(at)gmail(dot)com>
Subject: Re: Refactor query normalization into core query jumbling
Date: 2026-04-05 12:04:53
Message-ID: adJP5aQ3TE5ay1J5@paquier.xyz
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Apr 01, 2026 at 12:55:28AM -0700, Lukas Fittl wrote:
> On Tue, Mar 31, 2026 at 7:54 PM Sami Imseih <samimseih(at)gmail(dot)com> wrote:
>>
>> > 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.

FWIW, this search points to a lot of forks

> See attached a v9 that extracts ComputeConstantLengths from Sami's v7
> for easier discussion.
>
> I've done an updated test with pg_stat_monitor [0] and pg_tracing [1]
> with that, and that has both extensions passing regressions tests.
> I've also looked but not tested a third extension (sql_firewall) and
> that looks like it should just work as well.

Still I can see the gains here, so I guess that this version works
here. I'm happy enough to see the const with JumbleState.
--
Michael

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alexander Korotkov 2026-04-05 12:31:46 Re: Implement waiting for wal lsn replay: reloaded
Previous Message Alexander Lakhin 2026-04-05 12:00:00 Re: pg_plan_advice